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

Imports that are resolvable should not be reported as builtins #1007

Closed
wants to merge 1 commit into from
Closed

Imports that are resolvable should not be reported as builtins #1007

wants to merge 1 commit into from

Conversation

rixth
Copy link

@rixth rixth commented Jan 23, 2018

constants is a builtin (apparently) in node. however, if we can resolve the module name, we should assume that it is not a builtin.

Perhaps we could create a second rule that enforces not clobbering builtin names, but that behaviour shouldn't be part of this rule which is to enforce ordering.

@coveralls
Copy link

coveralls commented Jan 24, 2018

Coverage Status

Coverage increased (+0.007%) to 96.232% when pulling 27a5fad on rixth:improve_type_detection into b08bd3e on benmosher:master.

2 similar comments
@coveralls
Copy link

Coverage Status

Coverage increased (+0.007%) to 96.232% when pulling 27a5fad on rixth:improve_type_detection into b08bd3e on benmosher:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.007%) to 96.232% when pulling 27a5fad on rixth:improve_type_detection into b08bd3e on benmosher:master.

@rixth
Copy link
Author

rixth commented Jan 24, 2018

Not sure what the difference is between the travis build & the appveyor build (nor why the latter is failing)

@ljharb
Copy link
Member

ljharb commented Jan 26, 2018

however, if we can resolve the module name, we should assume that it is not a builtin.

Can you elaborate on this? In node, builtin names (like constants) take precedence no matter what's on the filesystem.

@j-f1
Copy link
Contributor

j-f1 commented Jan 26, 2018

@ljharb is correct:

Core modules are always preferentially loaded if their identifier is passed to require(). For instance, require('http') will always return the built in HTTP module, even if there is a file by that name.
source

@rixth
Copy link
Author

rixth commented Feb 1, 2018

@ljharb that may be so for just constants, but deeper paths eg constants/foo will be required as expected

@ljharb
Copy link
Member

ljharb commented Feb 2, 2018

Hmm, that's true - also constants/.

I wonder if it'd be simpler to change it so that if there's any path at all - ie, anything with a slash - that it's not a builtin?

@rixth
Copy link
Author

rixth commented Feb 7, 2018

@ljharb Happy to make this change -- would that be acceptable to you, or is there another contributor we should run this past?

@ljharb
Copy link
Member

ljharb commented Feb 7, 2018

I'd be happy to hear from @jfmengels or @benmosher on it, but both of them have been taking open source breaks for awhile now.

If there aren't any node builtins that have a / in the name, then this seems like the right way to address the bug.

@benmosher
Copy link
Member

I wonder if it'd be simpler to change it so that if there's any path at all - ie, anything with a slash - that it's not a builtin?

this makes sense to me if it matches the spec 👍

@rixth rixth closed this Mar 1, 2019
@ljharb
Copy link
Member

ljharb commented Mar 1, 2019

@rixth are you no longer interested in updating this PR?

@rixth
Copy link
Author

rixth commented Mar 1, 2019

@ljharb Correct - it is over a year old, conflicting, and I no longer work at the company/codebase where this was problematic. It was always an edge case at best.

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

Successfully merging this pull request may close these issues.

5 participants