Skip to content
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

import/order not working with @types packages #1552

Closed
peoplenarthax opened this issue Dec 3, 2019 · 8 comments
Closed

import/order not working with @types packages #1552

peoplenarthax opened this issue Dec 3, 2019 · 8 comments

Comments

@peoplenarthax
Copy link

Hello,

We are trying to work around import/order for our codebase but we face some difficulties as it seems that some external dependencies are recognised as internal.

We are using typescript and this makes imports a bit more peculiar, as when we try to import a package without types we most likely use the @types package for it (if it exists). This brings 2 problems:

  • First one, packages like react when analysing the path will be in a path like: ../../node_modules/@types/react instead of ../../node_modules/react, hence the path.indexOf function will fail as node_modules/react can't be found. We could say that there is a workaround this using import/external-modules-folder setting, pass both node_modules and node_modules/@types and it works. But this does not solve our second issue:

  • When a package with a name such as @loadable/component does not export types and we need to fetch it from @types, there is a impossibility to declare 2 workspaces ( @types/@loadable/component), and so it instead becomes @types/loadable__component. Which breaks the rule that try to find @loadable/components in the path.

Is there a work around this? I feel that to classify if a path is external it should be enough by checking if the folder directory appears in the path instead of check for folder\package what requires you to start having workarounds.

@ljharb
Copy link
Member

ljharb commented Dec 5, 2019

I believe #1491 will solve this.

@ljharb ljharb closed this as completed Dec 5, 2019
@BeeeQueue
Copy link

It does not. The problem is that (for example) @loadable/component is recognized as an internal import (if @types/loadable__component is installed) when it should be external.

import/internal-regex allows us to flag which packages are internal, not external.

@ljharb
Copy link
Member

ljharb commented Dec 12, 2019

I’m confused about how @types packages play into this; you don’t import from those directly, that’s just the package TS transparently uses when you import from the normal one.

@BeeeQueue
Copy link

Yes that's what should happen, but it isn't. We tried to debug why it wasn't working and found that this is what's happening.

@UberMouse
Copy link

UberMouse commented Jan 26, 2020

I think this issue should be reopened. It's still a real problem. I'm not sure why (debugging with DEBUG=eslint-plugin-import:* doesn't seem to provide helpful information for this) but every package with an associated @types package is getting sorted alongside my monorepo internal @foo scoped packages, instead of being placed with the external packages.

I tried to fix it with the pathGroups setting of import/order but it doesn't seem to match against @types.

@OzzieOrca
Copy link

OzzieOrca commented May 7, 2020

'import/external-module-folders': ['node_modules', '@types'], seems to have made this work again. Anything Typescript was finding in my root @types folder was getting sorted wrongly without this. Here's more of my config (with some rules omitted):

module.exports = {
  root: true,
  parser: '@typescript-eslint/parser',
  parserOptions: {
    ecmaVersion: 6,
    sourceType: 'module',
    ecmaFeatures: {
      jsx: true,
    },
  },
  rules: {
    'import/order': [
      'error',
      {
        'newlines-between': 'always',
      },
    ],
  },
  settings: {
    'import/resolver': {
      // config for eslint-import-resolver-typescript package
      typescript: {
        alwaysTryTypes: true,
        directory: './tsconfig.json',
      },
    },
    'import/external-module-folders': ['node_modules', '@types'],
    react: {
      version: 'detect',
    },
  },
  extends: [
    'prettier',
    'eslint:recommended',
    'plugin:react/recommended',
    'plugin:@typescript-eslint/eslint-recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:import/errors',
    'plugin:import/warnings',
    'plugin:import/typescript',
  ],
  plugins: ['@typescript-eslint', 'react', 'import', 'react-hooks'],
};

@zaverden
Copy link

I had same issue: react, lodash and other 3rd-party fell into internal group somehow.

An update "2.20.0" -> "2.20.2" has fixed the issue.

@ljharb
Copy link
Member

ljharb commented May 19, 2020

I'm going to close this as resolved; but will be happy to reopen if v2.20.2 doesn't solve it for someone.

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

No branches or pull requests

6 participants