npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

cdm-webpack-node-externals

v1.5.6

Published

Easily exclude node_modules in Webpack bundle

Downloads

2

Readme

Webpack node modules externals

Easily exclude node modules in Webpack

Version Downloads Build Status

Webpack allows you to define externals - modules that should not be bundled.

When bundling with Webpack for the backend - you usually don't want to bundle its node_modules dependencies. This library creates an externals function that ignores node_modules when bundling in Webpack.(Inspired by the great Backend apps with Webpack series)

Quick usage

npm install webpack-node-externals --save-dev

In your webpack.config.js:

var nodeExternals = require('webpack-node-externals');
...
module.exports = {
    ...
    target: 'node', // in order to ignore built-in modules like path, fs, etc.
    externals: [nodeExternals()], // in order to ignore all modules in node_modules folder
    ...
};

And that's it. All node modules will no longer be bundled but will be left as require('module').

Detailed overview

Description

This library scans the node_modules folder for all node_modules names, and builds an externals function that tells Webpack not to bundle those modules, or any sub-modules of theirs.

Configuration

This library accepts an options object.

options.whitelist (=[])

An array for the externals to whitelist, so they will be included in the bundle. Can accept exact strings ('module_name'), regex patterns (/^module_name/), or a function that accepts the module name and returns whether it should be included. Important - if you have set aliases in your webpack config with the exact same names as modules in node_modules, you need to whitelist them so Webpack will know they should be bundled.

options.importType (='commonjs')

The method in which unbundled modules will be required in the code. Best to leave as commonjs for node modules.

options.modulesDir (='node_modules')

The folder in which to search for the node modules.

options.modulesFromFile (=false)

Read the modules from the package.json file instead of the node_modules folder.

Example

var nodeExternals = require('webpack-node-externals');
...
module.exports = {
    ...
    target: 'node', // important in order not to bundle built-in modules like path, fs, etc.
    externals: [nodeExternals({
        // this WILL include `jquery` and `webpack/hot/dev-server` in the bundle, as well as `lodash/*`
        whitelist: ['jquery', 'webpack/hot/dev-server', /^lodash/]
    })],
    ...
};

For most use cases, the defaults of importType and modulesDir should be used.

Q&A

Why not just use a regex in the Webpack config?

Webpack allows inserting regex in the externals array, to capture non-relative modules:

{
    externals: [
        // Every non-relative module is external
        // abc -> require("abc")
        /^[a-z\-0-9]+$/
    ]
}

However, this will leave unbundled all non-relative requires, so it does not account for aliases that may be defined in webpack itself. This library scans the node_modules folder, so it only leaves unbundled the actual node modules that are being used.

How can I bundle required assets (i.e css files) from node_modules?

Using the whitelist option, this is possible. We can simply tell Webpack to bundle all files with extensions that are not js/jsx/json, using this regex:

...
nodeExternals({
  // load non-javascript files with extensions, presumably via loaders
  whitelist: [/\.(?!(?:jsx?|json)$).{1,5}$/i],
}),
...

Thanks @wmertens for this idea.

Why is not bundling node_modules a good thing?

When writing a node library, for instance, you may want to split your code to several files, and use Webpack to bundle them. However - you wouldn't want to bundle your code with its entire node_modules dependencies, for two reasons:

  1. It will bloat your library on npm.
  2. It goes against the entire npm dependencies management. If you're using Lodash, and the consumer of your library also has the same Lodash dependency, npm makes sure that it will be added only once. But bundling Lodash in your library will actually make it included twice, since npm is no longer managing this dependency.

As a consumer of a library, I want the library code to include only its logic, and just state its dependencies so they could me merged/resolved with the rest of the dependencies in my project. Bundling your code with your dependencies makes it virtually impossible.

In short: It's useful if your code is used by something that has dependencies managed by npm

Contribute

Contributions and pull requests are welcome. Please run the tests to make sure nothing breaks.

Test

npm run test

License

MIT