Gathering detailed insights and metrics for rollup-plugin-node-externals
Gathering detailed insights and metrics for rollup-plugin-node-externals
Gathering detailed insights and metrics for rollup-plugin-node-externals
Gathering detailed insights and metrics for rollup-plugin-node-externals
npm install rollup-plugin-node-externals
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
83 Stars
164 Commits
4 Forks
3 Watching
2 Branches
3 Contributors
Updated on 18 Nov 2024
TypeScript (95.78%)
JavaScript (4.22%)
Cumulative downloads
Total Downloads
Last day
-6.3%
18,043
Compared to previous day
Last week
10.2%
124,867
Compared to previous week
Last month
17.4%
462,789
Compared to previous month
Last year
28.8%
3,745,801
Compared to previous year
A Rollup/Vite plugin that automatically declares NodeJS built-in modules as external
. Also handles npm dependencies, devDependencies, peerDependencies and optionalDependencies.
Works in npm/yarn/pnpm/lerna monorepos too!
By default, Rollup doesn't know a thing about NodeJS, so trying to bundle simple things like import path from 'node:path'
in your code generates an Unresolved dependencies
warning.
The solution here is quite simple: you must tell Rollup that the node:path
module is in fact external. This way, Rollup won't try to bundle it in and rather leave the import
statement as is (or translate it to a require()
call if bundling for CommonJS).
However, this must be done for each and every NodeJS built-in you happen to use in your program: node:path
, node:os
, node:fs
, node:url
, etc., which can quickly become cumbersome when done manually.
So the primary goal of this plugin is simply to automatically declare all NodeJS built-in modules as external.
As an added bonus, this plugin will also allow you to declare your dependencies (as per your local or monorepo package.json
file(s)) as external.
Use your favorite package manager. Mine is npm.
1npm install --save-dev rollup-plugin-node-externals
The plugin is available both as the default export and as a named export:
1import nodeExternals from 'rollup-plugin-node-externals'
and
1import { nodeExternals } from 'rollup-plugin-node-externals'
will both work.
You generally want to have your runtime dependencies (those that will be imported/required at runtime) listed under dependencies
in package.json
, and your development dependencies (those that should be bundled in by Rollup) listed under devDependencies
.
If you follow this simple rule, then the default settings are just what you need:
1// rollup.config.js 2 3export default { 4 ... 5 plugins: [ 6 nodeExternals(), 7 ] 8}
This will bundle your devDependencies
in while leaving your dependencies
, peerDependencies
and optionalDependencies
external.
Should the defaults not suit your case, here is the full list of options.
1import nodeExternals from 'rollup-plugin-node-externals' 2 3export default { 4 ... 5 plugins: [ 6 nodeExternals({ 7 8 // Make node builtins external. Default: true. 9 builtins?: boolean 10 11 // node: prefix handing for importing Node builtins. Default: 'add'. 12 builtinsPrefix?: 'add' | 'strip' | 'ignore' 13 14 // The path(s) to your package.json. See below for default. 15 packagePath?: string | string[] 16 17 // Make pkg.dependencies external. Default: true. 18 deps?: boolean 19 20 // Make pkg.devDependencies external. Default: false. 21 devDeps?: boolean 22 23 // Make pkg.peerDependencies external. Default: true. 24 peerDeps?: boolean 25 26 // Make pkg.optionalDependencies external. Default: true. 27 optDeps?: boolean 28 29 // Modules to force include in externals. Default: []. 30 include?: string | RegExp | (string | RegExp)[] 31 32 // Modules to force exclude from externals. Default: []. 33 exclude?: string | RegExp | (string | RegExp)[] 34 }) 35 ] 36}
Set the builtins
option to false
if you'd like to use some shims/polyfills for those. You'll most certainly need an other plugin as well.
How to handle the node:
scheme used in recent versions of Node (i.e., import path from 'node:path'
).
add
(the default, recommended), the node:
scheme is always added. In effect, this dedupes your imports of Node builtins by homogenizing their names to their schemed version.strip
, the scheme is always removed. In effect, this dedupes your imports of Node builtins by homogenizing their names to their unschemed version. Schemed-only builtins like node:test
are not stripped.ignore
will simply leave all builtins imports as written in your code.Note that scheme handling is always applied, regardless of the
builtins
options being enabled or not.
If you're working with monorepos, the packagePath
option is made for you. It can take a path, or an array of paths, to your package.json file(s). If not specified, the default is to start with the current directory's package.json then go up scan for all package.json
files in parent directories recursively until either the root git directory is reached, the root of the monorepo is reached, or no other package.json
can be found.
Set the deps
, devDeps
, peerDeps
and optDeps
options to false
to prevent the corresponding dependencies from being externalized, therefore letting Rollup bundle them with your code.
Use the include
option to force certain dependencies into the list of externals, regardless of other settings:
1nodeExternals({
2 deps: false, // Deps will be bundled in
3 include: 'fsevents' // Except for fsevents
4})
Conversely, use the exclude
option to remove certain dependencies from the list of externals, regardless of other settings:
1nodeExternals({
2 deps: true, // Keep deps external
3 exclude: 'electron-reload' // Yet we want `electron-reload` bundled in
4})
include
and exclude
are silently ignored. This allows for conditional constructs like exclude: process.env.NODE_ENV === 'production' && 'my-prod-only-dep'
.include: /^lodash/
will externalize lodash
and also lodash/map
, lodash/merge
, etc.It uses an exact match against your imports as written in your code. No resolving of path aliases or substitutions is made:
1// In your code, say '@/lib' is an alias for source/deep/path/to/some/lib: 2import something from '@/lib'
If you don't want lib
bundled in, then write:
1// In rollup.config.js:
2nodeExternals({
3 include: '@/lib'
4})
If you're also using @rollup/plugin-node-resolve
, make sure this plugin comes before it in the plugins
array:
1import nodeExternals from 'rollup-plugin-node-externals' 2import nodeResolve from '@rollup/plugin-node-resolve' 3 4export default { 5 ... 6 plugins: [ 7 nodeExternals(), 8 nodeResolve(), 9 ] 10}
Note that as of version 7, this plugin's resolveId
hook has a order: 'pre'
property that will make Rollup call it very early in the module resolution process. Nevertheless, it is best to always make this plugin the first one in the plugins
array.
Rollup's own external
configuration option always takes precedence over this plugin. This is intentional.
While this plugin has always been compatible with Vite, it was previously necessary to use the following vite.config.js
to make it work reliably in every situation:
1import { defineConfig } from 'vite' 2import nodeExternals from 'rollup-plugin-node-externals' 3 4export default defineConfig({ 5 ... 6 plugins: [ 7 { enforce: 'pre', ...nodeExternals() }, 8 // other plugins follow 9 ] 10})
Since version 7.1, this is no longer necessary and you can use the normal syntax instead. You still want to keep this plugin early in the plugins
array, though.
1import { defineConfig } from 'vite' 2import nodeExternals from 'rollup-plugin-node-externals' 3 4export default defineConfig({ 5 ... 6 plugins: [ 7 nodeExternals() 8 // other plugins follow 9 ] 10})
externals
named export has been removed.^3.0.0 || ^4.0.0
.devDeps
option defaulted to true
.devDeps
option now defaults to false
, meaning Rollup will include them in your bundle.builtinsPrefix
option now defaults to 'add'
.prefixedBuiltins
option has been removed. Use builtinsPrefix
instead.rollup-plugin-node-externals
no longer depends on the Find-Up package (while this is not a breaking change per se, it can be in some edge situations).rollup ^2.60.0 || ^3.0.0
.deps
option defaulted to false
.deps
option now defaults to true
.rollup ^2.60.0
.MIT
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
no dangerous workflow patterns detected
Reason
project is fuzzed
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
4 existing vulnerabilities detected
Details
Reason
Found 0/30 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
no SAST tool detected
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
license file not detected
Details
Score
Last Scanned on 2024-11-25
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More