[x] yes (bugfixes and features will not be merged without tests)
[ ] no
Breaking Changes?
[ ] yes (breaking changes will not be merged unless absolutely necessary)
[x] no
If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.
List any relevant issue numbers: resolves #1655
Description
I think #1665 proposes a nice feature that gives preferBuiltins a more fine-grained control, so I'm trying to resolve this a little inactive issue.
This PR only makes node-resolve accept a function parameter to preferBuiltins to introduce as little as possible without changing the existing API.
1665 also proposes that it should match the behavior of the external rollup configuration. But I think in most cases, we only need to mark some modules as non-builtins, e.g., deprecated modules like punycode. And this is somehow contrary to the behavior of the external.
Is accepting a function enough or should we add some extra configs? I'm willing to contribute if we need to make more changes.
Rollup Plugin Name:
@rollup/plugin-node-resolveThis PR contains:
Are tests included?
Breaking Changes?
If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.
List any relevant issue numbers: resolves #1655
Description
I think #1665 proposes a nice feature that gives
preferBuiltinsa more fine-grained control, so I'm trying to resolve this a little inactive issue.This PR only makes
node-resolveaccept a function parameter topreferBuiltinsto introduce as little as possible without changing the existing API.1665 also proposes that it should match the behavior of the
externalrollup configuration. But I think in most cases, we only need to mark some modules as non-builtins, e.g., deprecated modules likepunycode. And this is somehow contrary to the behavior of theexternal.Is accepting a function enough or should we add some extra configs? I'm willing to contribute if we need to make more changes.