Skip to content

Request: Grouping of imports #493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
LinusU opened this issue Feb 20, 2023 · 8 comments
Open

Request: Grouping of imports #493

LinusU opened this issue Feb 20, 2023 · 8 comments

Comments

@LinusU
Copy link

LinusU commented Feb 20, 2023

We are currently enforcing grouping of imports in our file, using the import/order ESLint rule.

This is our config:

    'import/order': [2, {
      groups: [
        ['builtin', 'external'],
        ['parent'],
        ['sibling', 'index']
      ],
      'newlines-between': 'always'
    }],

It makes it so that our imports are grouped into three sections, always separated by an empty line. Example:

import { Temporal } from '@js-temporal/polyfill'
import React from 'react'
import Spacer from 'react-spacer'
import { HStack, Text, TextStyle, VStack } from 'react-stacked'

import { FullPhysicalControlUnitOutageFragment } from '../../types/graphql'
import formatDateTime from '../util/formatDateTime'

import { PrimaryButton } from './Buttons'
import ListItemWrapper from './ListItemWrapper'

// ...

I would love to see this as an option to dprint, as I believe that this is the only ESLint rule we have that enforces a particular coding style. (aside from that we only use ESLint to enforce actual problems with the code.) Currently, this is not fixed automatically on save for our developers, as we are using dprint as the formatter in VS Code. This can make it easy to submit a PR that fails CI because the imports are not grouped correctly, since most import statements are inserted automatically by the editor.

@adrian-gierakowski
Copy link

👍

@sirreal
Copy link

sirreal commented Mar 31, 2023

One motivator to switch to dprint for a project I work on was the sorting of imports. Previously, we were enforcing import order via eslint, which was a poor experience. It really seems like something a formatter should handle.

I'd love to have an option where dprint hoists all the imports into a single group and sorts them. The way it sorts imports but only in contiguous groups leaves us in a strange middle territory. Imports are ordered, but devs regularly mention that imports aren't ordered as they'd expect, because dprint is only sorting imports inside contiguous blocks, it doesn't touch anything separated by newlines.

@jakebailey
Copy link
Contributor

Note that there's also a popular grouper, eslint-plugin-simple-import-order, which is also widely used and does things differently.

Personally, I don't think that trying to implement all of the options is a good idea; the approach that TypeScript's own formatter takes is to just preserve the groups and then maybe resort them based on the detected order (or, WIP in 5.0, based on a specific user-specified ordering). But guessing the correct grouping seems really hard.

@todor-a
Copy link
Contributor

todor-a commented Apr 3, 2024

@dsherret is this something that you can see having a place in dprint? I'm interested in giving this a go but I'm not sure how would the config API should look like and if it's something that dprint wants to concern itself with.

@jakebailey
Copy link
Contributor

FWIW my opinion here changed a bit having dealt with using ESLint on TS itself now that we're modules; using dprint to group would be a lot faster and less annoying...

I do like the flexibility that eslint-plugin-simple-import-order has for creating groups and orderng them, but I also don't wish a large configuration space on anyone 😄

@todor-a
Copy link
Contributor

todor-a commented Apr 3, 2024

Can you provide a pseudo-config of how you imagine a config might look like?

@jakebailey
Copy link
Contributor

jakebailey commented Apr 3, 2024

I would be hoping for something as powerful as: https://github.com/lydell/eslint-plugin-simple-import-sort/#custom-grouping

The way that the sorting works is kind of odd, in that it uses only regexes, then a special unicode character to distinguish side effect imports; each group is an array of regexes that should be in that group.

It's not my favorite, but I don't know if I have a specific alternative to that in mind. In a way it's nice to be able to sort solely on specifier strings with just other strings... 😄 But it's still confusing without reading docs.

@metawrap-dev
Copy link

metawrap-dev commented Apr 20, 2025

The lack of native import ordering (grouping) is a real oversight.

The dprint imporg plugin is non-functional and possibly abandoned.

I am stuck with using dprint for my onsave formatting and prettier+trivago for batch runs to tidy things up.

Dprint: Great if you only need fast code formatting.
Biome: Promising but missing features
Imporg: Dead? .
Prettier+Trivago plugin: Battle-tested and still the best choice for import management today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants