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

Rule proposal: no-core #158

Closed
gajus opened this issue Jan 26, 2016 · 4 comments · Fixed by #261
Closed

Rule proposal: no-core #158

gajus opened this issue Jan 26, 2016 · 4 comments · Fixed by #261

Comments

@gajus
Copy link
Contributor

gajus commented Jan 26, 2016

I have seen client app code import Node.js modules, e.g.

import querystring from 'querystring';

This will potentially import a huge library that will vary depending on the node version used to build the bundle. Bundle should not depend on the version of node used to build it.

This is hard to catch because it will just work until it suddenly stops with no way to traceback the issue in the code itself.

The rule should restrict import to only modules declared in package.json (or another strategy used to make sure that Node.js modules are not imported).

@benmosher
Copy link
Member

Ooo, interesting. Seems to be a similar rule to #126, maybe a {core: false} option on such a rule.

@benmosher
Copy link
Member

need #126 first, to avoid rework, I think. thus the accepted label toggle.

@jfmengels
Copy link
Collaborator

Pretty easy to add, I don't mind adding it. Most of the code needed has been written in eslint-plugin-import-order https://github.com/jfmengels/eslint-plugin-import-order/blob/master/utils.js#L12-L14. It's similar to #126 but doesn't need to have IO since the list of builtin modules is known (and pretty stable too I think).

@benmosher
Copy link
Member

@jfmengels works for me!

FWIW the resolvers return {found: true, path: null} for core modules, but I can't think of any cases where this beats a hardcoded list.

Only benefit is that substack/resolve is responsible for maintaining the list. (assuming that's how it's implemented, I haven't looked closely at resolve.isCore)

So fine to start there, at least. I think I'd probably like to ultimately use the resolvers for consistency, but that's just an implementation detail, and I think it can be amended later as a non-breaking change.

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

Successfully merging a pull request may close this issue.

3 participants