[import/extensions] complains on importing a relative folder

[codehimanshu]

The import statement I used in module.js looks like this:

const { errors } = require('../config')

My directory structure is like this:

app
├── src
│   ├── module.js
├── config
│   ├── index.js
│   ├── errors.js
|...

Since this is a relative import and the module is a folder which exports all its submodules from index.js, import/extensions should not complaint about this.

[ljharb]

How do you have the extensions rule configured?

[maicol07]

@ljharb I have this issue too. Here is my configuration:

{
'import/extensions': ['error',
      {
        js: 'always',
        ts: 'never',
        jsx: 'never',
        tsx: 'never',
        json: 'always',
        png: 'always',
        css: 'always',
        scss: 'always'
      }
    ]
}

[ljharb]

@maicol07 ok, and what filename are you importing, with what specifier?

[maicol07]

@ljharb a folder, in my case it's a subpackage of mithril:

import stream from 'mithril/stream`

mithril/stream is a folder

[ljharb]

Sure, but it maps to a JS file, so the rule requires the extension, per your config. https://unpkg.com/browse/mithril@2.0.4/stream/stream.js

Although, it has its own package.json, which suggests it's published as mithril-stream - is it also available bundled?

[maicol07]

Yes, but they will probably remove it in future versions. What about adding a new setting like ignorePackages for this one?

[ljharb]

Why do you want to force .js for your first-party files? How does that rationale not apply to files from packages?

[maicol07]

No, I don't mean I want to use ignorePackages. I want a new option to ignore files with a folder with the same name

[ljharb]

ok, so whether it's relative or in a package, you want any foo/bar/bar.js to be foo/bar? that's just a coincidence here tho - the default "main" for a folder is index.js, and it's arbitrary that mithril has named the main file "stream.js".

What I'm asking is, why do you have js set to "always", instead of the much more common "never"? (The answer to that question is important, because it informs what would make sense as a rule option here)

[maicol07]

Because I have other packages, such as lit where you must import directives by file. Example:

import {
  customElement,
  property
} from 'lit/decorators.js';
import {ifDefined} from 'lit/directives/if-defined.js';

[ljharb]

Sure - but if mithril/stream is ok, why isn't lit/decorators ok? If lit/decorators.js is preferred, why isn't mithril/stream/stream.js preferred?

To me, they're all in the same bucket - either neither of them have extensions (the ecosystem's overwhelming preference), or both of them do.

[maicol07]

That's because I would like to use mithril/stream, since it is shorter. The lit one is preferred because it cannot be imported in any other way. So, while I can write mithril/stream, ai can't write lit/decorators

[ljharb]

Why can't it be imported another way? lit/decorators should work just fine, since the .js is implicit in transpiled ESM and CJS.

[ljharb]

I do see line 26 in https://unpkg.com/browse/lit@2.2.0/package.json - so this seems more like you should want eslint to be configured for "never", but lit has used exports to force you to write it with the bloat of the extension.

In other words, it seems like lit needs the configuration exception here (until we support "exports", at which point it'd automatically work) - but better would be to ask lit to add an exports entry that omits the extension.

[maicol07]

It seems lit Devs won't change that: https://github.com/lit/lit/discussions/2626#discussioncomment-2313720