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.
We are currently enforcing grouping of imports in our file, using the
import/orderESLint rule.This is our config:
It makes it so that our imports are grouped into three sections, always separated by an empty line. Example:
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.