Closed bterlson closed 5 years ago
Only some vague thoughts for now:
Therefore if I understand you correctly, 2. might actually be a viable option
You can use resolve/lib/core
, and if the key is in that object and the value is true, it's a builtin module.
That rationale seems sound to me, let's go with 2! Should be nearly a one-liner. And yeah, I'll use Resolve's isBuiltin thing here, rather than following what rollup-plugin-node-builtins does (that plugin should probably just use resolves thing too).
One open question could be how to handle version ranges for builtins that are specified for resolve but I guess we should just use all of them as we do not know on which target system we will run.
@lukastaegert the "core" logic in resolve is written to assume that you're running it on a node version that matches the author's expectations. iow, if they're running on node 6, then only the core modules in node 6 are considered eligible (since the input code isn't written for the target environment, it's written for node)
Resolve changed how it resolves built-in module specifiers like
buffer
(this also impacted rollup-plugin-node-resolve). The impact is you can no longer add exports for e.g.assert
like the following:This plugin starts by building a map from resolved module path to declared named exports for that module. The resolve change means the keys for built-in modules went from a resolved path to the like-named npm module to simply returning the built-in name back.
I see three potential fixes here:
Do the maintainers have any thoughts on the best fix here?