Using --external:./node_modules/* results in relative import instead of bare import

[supachailllpay]

From entry.js:

import React from 'react'

Run build:

esbuild entry.js --bundle --outfile=out.js --format=esm --external:"./node_modules/*"

Then out.js:

import React from "./node_modules/react/index.js";

But if I just exclude react directly:

esbuild entry.js --bundle --outfile=out.js --format=esm --external:react

Then the result will be:

import React from "react";

Or if I use the plugin below to manually exclude all packages from node_modules. The result will still be a bare import.

let makeAllPackagesExternalPlugin = {
  name: 'make-all-packages-external',
  setup(build) {
    let filter = /^[^.\/]|^\.[^.\/]|^\.\.[^\/]/ // Must not start with "/" or "./" or "../"
    build.onResolve({ filter }, args => ({ path: args.path, external: true }))
  },
}

Originally posted by @evanw in #619 (comment)

So I'm not sure if this is the intended behavior or bug?. And if this is intended, how can I do this without using a plugin?

Thank you.

[matthiasg]

I just stumbled into this as well. This causes npx to be broken though as the node_modules folder is not created in the same location after 'install'.

[maximilianschmitt]

I've also encountered this issue while trying to use esbuild to bundle some TS code for an Electron application. import ejs from 'ejs' becomes require("../../node_modules/ejs/lib/ejs.js") in the resulting bundle which then creates issues when run with Electron because when bundling the application, the node_modules move relative to the entry-file.

[StarpTech]

Hi, I run into this as well. This only happens for require imports. It would be great to have a continuation on this. As a workaround, I mark all packages in node_modules as external.

[ShravanSunder]

i'm also running into this with juliencrn/usehooks-ts#97
dependant modules are turned into common js

[jakebailey]

Not sure if you've already considered it, but this would be a great breaking change to include in something like #2508.

I've personally worked around this by doing something like const moduleName = "source-map-support" and then require-ing that, since I need to enable that if it works (but there's no guarantee that any particular version of that library has the final mapped path).

EDIT: Don't do the above... Just do --external:source-map-support; doh.

[jakebailey]

I think that this is the same bug, but one thing I've noticed is that if you set --external:./node_modules/* but are targeting the CJS format, you will end up with code like:

chai = __toESM(require("../../node_modules/chai/index.mjs"));

Which will fail to work since that's not CJS code. If the code had not been external, this would have been fine since it'd be bundled and so the MJS-ness of the file would not matter.

Setting the conditions to be require fixes things, but it'd be best to emit require("chai") as the original code wrote. (Of course you shouldn't ship this to anyone; their version of the lib may use a different path; in my case it's a test bundle so it's fine.)

[jakebailey]

After viewing some of the cross-linked PRs, I realized that I had completely glossed over the fact that you can just specify each package name as "external" directly, rather than using a wildcard. With that in mind, I've ended up going with using a plugin that enforces that "external" is fully configured:

{
    name: "no-node-modules",
    setup: (build) => {
        build.onLoad({ filter: /[\\/]node_modules[\\/]/ }, () => {
            // See: https://github.com/evanw/esbuild/issues/1958
            return {
                errors: [{ text: 'Attempted to bundle from node_modules; ensure "external" is set correctly.' }]
            };
        });
    }
},

This gives me a handy error at bundle time:

This is plenty for my needs.