Mark all node_modules as external

tsup right now has an issue with node modules with files inside the module that are not the main file (for example, import { foo } from "bar/baz"), and it always tries to bundle them, which pretty much always is a non-desired behavior. And even breaks when outputting to esm, since it tries to bundle commonjs inside the esm modules

evanw gave a solution as a plugin mentioned here: https://github.com/evanw/esbuild/issues/619#issuecomment-751995294

I tested it locally and it works fine, but I would need some feedback in how to enable this behaviour, the cleanest one I could thought off is reading the moduleResolution: "node" in the tsconfig, since having that it should assume you are dealing with outputting for Node.js, but maybe a very small flag in the CLI would be a good solution too, like “tsup src/index.ts --node”

[mindplay-dk]

tsup right now has an issue with node modules with files inside the module that are not the main file (for example, import { foo } from "bar/baz"), and it always tries to bundle them, which pretty much always is a non-desired behavior.

Why? I thought bundling dependencies was the point of using a bundler?

I found this in the README as well:

By default tsup bundles all import-ed modules but dependencies in your packages.json are always excluded

This also doesn’t explain why? (It probably should?)

My simple use-case is a library that internally uses fast-deep-equal - I consider that an implementation detail, not something someone should need to install; I want to ship a single .js file with no dependencies, with the expected version of this library built-in, and so on.

Is this unusual? It seems to be default behavior of other bundlers, e.g. webpack, rollup - and for that matter esbuild, which it sounds like you needed a plugin or workaround to suppress that?

In my experience, dependencies are usually bundled by default, unless listed as externals somehow - whereas peerDependencies are not?

I found this very confusing - and the manual doesn’t seem to mention any opt-out?

If you’re not going to follow the typical pattern of bundlers bundling by default, with externals as an opt-out, perhaps you might consider an internals switch to reverse this behavior for libraries where you do want to bundle something?

[mindplay-dk]

For the record, moving this dependency to devDependencies fixed it - and it’s probably the right solution, since this is not a dependency in the npm sense, but only a build-time dependency.

Putting it there feels a bit odd, as it’s not the advice you’re normally given - but it also kind of makes sense, given that it won’t be an install-time dependency.

If that’s the correct approach, this should probably be mentioned in documentation? It probably won’t be obvious to most users, given that this is not how most bundlers behave by default?