-
-
Notifications
You must be signed in to change notification settings - Fork 599
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
Node-resolve: refactor handling builtins, do not log warning if no local version #637
Node-resolve: refactor handling builtins, do not log warning if no local version #637
Conversation
…resolve-refactor-builtins
packages/node-resolve/src/index.js
Outdated
@@ -258,9 +258,20 @@ export function nodeResolve(opts = {}) { | |||
idToPackageInfo.set(resolved, packageInfo); | |||
|
|||
if (hasPackageEntry) { | |||
if (builtins.has(resolved) && preferBuiltins && isPreferBuiltinsSet) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty sure resolved === importee
here because we were depending on resolve()
agreeing on it being a builtin and resolving to the same thing (given we didn't add importSpecifierList.push(`${importee}`)
). Therefore builtins.has(resolved)
is the same as importeeIsBuiltin
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Actually I'm not sure if this is going to warn for all builtins even when there isn't a local version available. Moving this back to a draft |
This wasn't handled before either, so now this includes a fix for that too. We no longer log a warning for a builtin if there was no local version. |
https://www.npmjs.com/package/browser-resolve exists, and has been used by browserify since it invented the concept of a bundler - why not use that? |
Personally, I'm not a fan of depending upon another bundler's implementation of a thing. @ljharb your comment seems better suited to a |
This comment has been minimized.
This comment has been minimized.
@ljharb While we have been happily using your We had a custom logic for this for a long time and I suspect the reason is that it allows greater control over when to use the I would not completely dismiss this in general, though. Your resolve package has shown that it is very well-cacheable, giving this plugin a nice speed-boost over vanilla Rollup, so there could be some upsides from using browser-resolve as well. I do not know why it was not used originally, though, that was before my time. But @shellscape is right, this should be another issue, but not of the magnitude of replacing node-resolve but rather changing the core-resolve from https://www.npmjs.com/package/resolve to https://www.npmjs.com/package/browser-resolve |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I assume not merging this is blocking progress on #627?
packages/node-resolve/README.md
Outdated
@@ -129,7 +129,7 @@ DEPRECATED: use "resolveOnly" instead | |||
### `preferBuiltins` | |||
|
|||
Type: `Boolean`<br> | |||
Default: `true` | |||
Default: `true` (with warnings if a builtin module is used over a local version. Set to `true` to disable warning.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@@ -201,7 +201,7 @@ export function nodeResolve(opts = {}) { | |||
|
|||
const importeeIsBuiltin = builtins.has(importee); | |||
|
|||
if (importeeIsBuiltin && (!preferBuiltins || !isPreferBuiltinsSet)) { | |||
if (importeeIsBuiltin) { | |||
// The `resolve` library will not resolve packages with the same |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't the logic here become superfluous by using the new option in the updated resolve
package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep! Am looking into that in a different branch though.
packages/node-resolve/src/index.js
Outdated
@@ -258,9 +258,20 @@ export function nodeResolve(opts = {}) { | |||
idToPackageInfo.set(resolved, packageInfo); | |||
|
|||
if (hasPackageEntry) { | |||
if (builtins.has(resolved) && preferBuiltins && isPreferBuiltinsSet) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Nope. I don't think there's anything left to do address there right now. |
@tjenkinson I merged #627 a little bit ago and it caused a few conflicts. Please have a look |
@shellscape done |
Rollup Plugin Name:
node-resolve
This PR contains:
Are tests included?
Breaking Changes?
Description
This slightly simplifies how the
preferBuiltins
default value is handled. NowisPreferBuiltinsSet
is only used for determining when to show the log message and not in some of the other decisions.Currently the plugin uses
builtin-modules
package to determine if a module is a builtin, but theresolve
package usesis-core-module
so there is a bit of a mismatch and room for errors here (e.g. we don't think the id is a builtin, butresolve
does. I think then we would let it through even if the user setpreferBuiltins: false
. Or we think it's a builtin, butresolve
disagrees and finds nothing, so we end up bailing out early) . I think it would be better if we could tell theresolve
plugin to not resolve builtins, and then we would have the source of truth for builtins. Will open with an PR for an option for this in theresolve
repo