v2.0.0 prefers '.d.ts' files to '.js' files when both exist.

[jgerigmeyer]

In v2.0.0, it seems that the change from:

  const extensions = Object.keys(require.extensions).concat(
    '.ts',
    '.tsx',
    '.d.ts',
  );

to:

const extensions = ['.ts', '.tsx', '.d.ts'].concat(
  // eslint-disable-next-line node/no-deprecated-api
  Object.keys(require.extensions),
  '.jsx',
)

...means that if a node module is imported and contains both .js and .d.ts files, the .d.ts file is now resolved instead of the .js one. This results in import/default errors, e.g.:

import React from 'react';

error: No default export found in module (import/default)

Maybe I'm missing something obvious?

[JounQin]

Yes, it's just working as expected.
See #31 (comment)

[alexgorbatchev]

@JounQin would it make sense to document this behavior somewhere in README?

[joaovieira]

@JounQin Sorry, don't know what you mean by "it's working as expected". Both here and here. I'm having issues with lodash as well, just as in #31.

In all of these scenarios, there is a default export that always used to work (with esModuleInterop):

// node_modules/dataloader/index.d.ts
declare class DataLoader {}
export = DataLoader;

// node_modules/@types/lodash/snakeCase.d.ts
import { snakeCase } from "./index";
export = snakeCase;

So it's not working as we're expecting.

[JounQin]

It's not ES Module default export, it's commonjs, that why the eslint-plugin-import complains about no default export.

[JounQin]

And you should issue to eslint-plugin-import for help supporting that instead.

[joaovieira]

With esModuleInterop.

On top of those already mentioned, import/order also started to raise:

express: external types in @types/express - seen as "internal"
http-status-codes: own types - seen as "external"

I'm not that well versed in eslint-plugin-import and/or eslint-import-resolver-typescript to understand what is going on - or even where the boundaries are. So can't say yet where the problem is, but will dig deeper. But, as a consumer, it's not working as expected.

Regarding disabling the rules: typescript-eslint/typescript-eslint#154 (comment)

[JounQin]

esModuleInterop is TypeScript spec and eslint-plugin-import doesn't understand it, that's why I told you to issue to it instead.

And also, eslint-plugin-import considers foo and @types/foo as different packages, so it's still as expected on eslint-import-resolver-typescript's side.

Please, issue to eslint-plugin-import instead if it's not as expected for you.

[joaovieira]

Ok. For the import/order, I've raised import-js/eslint-plugin-import#1525 and fixed in import-js/eslint-plugin-import#1526.

For the import/default, where do you think the problem would be? In the parser or the import plugin?

In 1.1.1 reading from the JS source (lodash/snakeCase.js) works fine:

var snakeCase = createCompounder(function(result, word, index) {
  return result + (index ? '_' : '') + word.toLowerCase();
});

module.exports = snakeCase;

In 2.0.0 using the TS export syntax in the type definition (@types/lodash/snakeCase.d.ts) it doesn't work:

import { snakeCase } from "./index";
export = snakeCase;

[JounQin]

I've told you the type definition is commonjs format and eslint-plugin-import doesn't treat it as an ES Module then. It doesn't even know any compilerOptions about esModuleInterop.

And it's not regression in my opinion then, it's just the correct behavior. Of course, it could be better to support esModuleInterop for eslint-plugin-import, and there is nothing we can do on side of eslint-import-resolver-typescript.