Request: Grouping of imports

[LinusU]

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]

👍

[sirreal]

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]

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]

@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]

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]

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

[jakebailey]

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.