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

Add ability to include node built-in modules as external dependencies #303

Closed
wants to merge 7 commits into from
Closed

Conversation

krismuniz
Copy link

@krismuniz krismuniz commented Jan 18, 2019

Hello 👋

This PR adds the ability to include node built-in modules as external dependencies by specifying --external natives

Related to #288, but I'm not 100% sure if it closes it, as the PR suggests using the rollup-plugin-node-builtins plugin for resolving these dependencies and including shims where necessary (i.e. in the browser).

Problem

When using microbundle for building node modules (--target node), you have to include every built-in module like this:

microbundle --external events,util,child_process

This becomes even more tedious when a built-in module uses other built-in modules.

As @lukeed suggests in this comment, it would be nice to have the option to simply treat all built-in node modules as external dependencies by adding --external natives instead of --external events,util,child_process[, ...].

Solution

Add all modules from require('module').builtinModules to the list of external dependencies like this:

microbundle --external natives

Feedback Welcome

✏️Let me know if you need any changes
🗯If this is not ideal, what would be a nice alternative to specifying all built-in modules?

Copy link
Contributor

@lukeed lukeed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔥 You're killin' it @krismuniz~!

I wouldn't rush to change anything (others should weigh in first), but I think this should be on by default, replacing the minuscule natives-exception list (here).

Right now, using --external natives will prevent you from also making your (peer)dependencies external too, unless you declared them all individually, too.

If we have all natives on by default, a local dependency with the same name should/will already be external & should/will still be found when required.

@krismuniz
Copy link
Author

I think this should be on by default, replacing the minuscule natives-exception list (here).

@lukeed that would be even better! Something like this, right?

- let external = ['dns', 'fs', 'path', 'url'].concat(/* ... */);
+ let external = require('module').builtinModules.concat(/* ... */);

Right now, using --external natives will prevent you from also making your (peer)dependencies external too, unless you declared them all individually, too.

Indeed, if for some reason it were impractical to just include them by default we could also make natives equal all built-in node modules like this:

external = external.concat(peerDeps).concat(options.external.split(','));
// if options.external contains 'natives', include built-in modules
external = options.external.split(',').includes('natives')
  ? external.concat(require('module').builtinModules)
  : external;

If we have all natives on by default, a local dependency with the same name should/will already be external & should/will still be found when required.

💯yes, that would be the ideal scenario, imho

@lukeed
Copy link
Contributor

lukeed commented Jan 20, 2019

Something like this, right?

Correct!

The only other thing to consider here is that require('module').builtinModules doesn't work in Node 4.x – hence my two-part suggestion in the original issue. I don't know/can't remember the minimum supported Node version microbundle is targeting.

@Andarist
Copy link
Collaborator

I also agree that this should be the default with node as target, we could use this static list for this - https://github.com/sindresorhus/builtin-modules/blob/master/builtin-modules.json

@lukeed
Copy link
Contributor

lukeed commented Jan 20, 2019

Don't think we need an extra dependency – the list is built-in to Node in all versions:

require('module').builtinModules || Object.keys(process.binding('natives'))

@krismuniz
Copy link
Author

krismuniz commented Jan 21, 2019

Right! So if we want Node 4.x support we'd do something like this:

- let external = require('module').builtinModules.concat(/* ... */);
+ const builtinModules = require('module').builtinModules || Object.keys(process.binding('natives'));
/* ... */
+ builtinModules.concat(/* ... */);

Would this apply only when target === 'node'?

@developit
Copy link
Owner

developit commented Feb 13, 2019

@krismuniz it should only apply to target==='node' yup.

If we want to support both automatic builtin externals for target=node and --external natives, perhaps the following?

if (target=='node' && external.indexOf('natives')===-1) {
  external.push('natives');
}
// ...
const i = external.indexOf('natives');
if (i!==-1) {
  const builtins = require('module').builtinModules || Object.keys(process.binding('natives'));
  external.splice(i, 1, builtins);
}

@ianstormtaylor
Copy link

Any news on this? This would be super helpful.

@ForsakenHarmony
Copy link
Collaborator

Problems mentioned above would have to be solved

developit added a commit that referenced this pull request Apr 18, 2020
This option was enabled by default at some point in the node-resolve plugin, which should already have fixed #303 and #288. It still prints a warning though, which is illogical when we're compiling for a Node target. This silences that warning.
@developit
Copy link
Owner

developit commented Apr 18, 2020

FWIW this behavior is already enabled by default in microbundle@next, since rollup-plugin-node-resolve handles it by default. I've opened #591 to silence the warnings.

Note: we could still merge this PR, though I'm not sure it does anything as of the update.

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

Successfully merging this pull request may close these issues.

6 participants