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

Better handling of non-existent node_modules directory #271

Closed
sindresorhus opened this issue Apr 25, 2016 · 6 comments
Closed

Better handling of non-existent node_modules directory #271

sindresorhus opened this issue Apr 25, 2016 · 6 comments
Labels
Milestone

Comments

@sindresorhus
Copy link

I ran this plugin in a project without a node_modules directory. I hadn't yet run npm install.

This is what I got:

test.js:2
✖  2:18  Unexpected use of file extension "" for "ava"         import/extensions
✖  2:18  Unable to resolve path to module 'ava'.               import/no-unresolved
✖  3:23  Unexpected use of file extension "" for "read-chunk"  import/extensions
✖  3:23  Unable to resolve path to module 'read-chunk'.        import/no-unresolved

I don't think the import/extensions rule should report in this case. It's just noise.

@benmosher
Copy link
Member

benmosher commented Apr 27, 2016

Ah, yeah, seems like package refs (even internal ones) should should not trigger extensions (always mode).

@vvo: did you imagine the always mode would disallow package references? I would think that ought to be a separate rule, or at least an option.

i.e.

import foo from './foo.js' // valid

import bar from './bar' // invalid if filename is actually `bar.js`
import React from 'react' // valid if points to a package and not `react.js`

@vvo
Copy link

vvo commented May 1, 2016

Dunno about the "always mode" but your example is valid and expected.

@vvo
Copy link

vvo commented May 1, 2016

But

import bar from './bar' // invalid if filename is actually `bar.js`

Actually if there's a folder named "bar" I would want to disable requiring it. Requiring folders involves magic and hides the filetree from the code.

@benmosher
Copy link
Member

Fair enough. So: a flag (allow-packages) that allows a folder reference?

@benmosher
Copy link
Member

Actually I just realized that the main issue may be that the extensions rule needs to ignore unresolved imports.

This is a standard behavior that would resolve @sindresorhus's original issue regardless of what mode he put it in.

@benmosher benmosher added the bug label May 2, 2016
@benmosher benmosher added this to the next milestone May 2, 2016
benmosher added a commit that referenced this issue May 2, 2016
- use source path if unable to resolve (fixes #295, #271)
- don't enforce file extensions on builtins
benmosher added a commit that referenced this issue May 3, 2016
- use source path if unable to resolve (fixes #295, #271)
- don't enforce file extensions on builtins

changelog + docs updates for #296
benmosher added a commit that referenced this issue May 5, 2016
* formatting

* extensions fixes:
- use source path if unable to resolve (fixes #295, #271)
- don't enforce file extensions on builtins

changelog + docs updates for #296

* increase test timeout for Travis?
@benmosher
Copy link
Member

fixed by #296

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

No branches or pull requests

3 participants