Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You may not need a bundler for your NPM library

cmdcolin.github.io

Post reply on HN
Print view View original

21–30 of 40 posts

Re: You may not need a bundler for your NPM library

#21

Post by laundermaf »

andreareina wrote: post #8

- bundles let you ship less code (tree shaking) - dependency versions being fixed is a feature. I've had package installs fail because a dependency published a semver-compatible update that broke something. In a web context this would break the app until the dependency pulled the update or the dependent pushed an update disallowing that version.

> dependency versions being fixed is a feature

Pushing multiple versions of the same library is a bug. Semver ranges exist for a reason.

> a dependency published a semver-compatible update that broke something

The same can happen with your direct dependencies too. Just use a lockfile and only update it when the install is successful.

> In a web context this would break the app

Absolutely not. Use lockfiles. Nothing breaks until you merge that update PR.

Re: You may not need a bundler for your NPM library

#22

Post by laundermaf »

oefrha wrote: post #17
fckthisguy wrote: post #7

Earlier quoted context omitted.

And ship a commonjs version as well, if you need to support older node versions. It's trivial.

It’s actually pretty annoying that some people are now going pure esm and actively removing cjs builds. There are certain libraries that don’t work with esm yet, so if you need one of those suddenly all the esm-only packages can’t be used.

> certain libraries that don’t work with esm yet

I assume that you're talking about tools rather than libraries. Any simple library can import ESM asynchronously and any ESM packages can import CJS packages even with static imports.

Tools and Node’s strict ERR_REQUIRE_ESM have been the problem with the migration.

Re: You may not need a bundler for your NPM library

#24

Post by andreareina »

laundermaf wrote: post #21
andreareina wrote: post #8

- bundles let you ship less code (tree shaking) - dependency versions being fixed is a feature. I've had package installs fail because a dependency published a semver-compatible update that broke something. In a web context this would break the app until the dependency pulled the update or the dependent pushed an update disallowing that version.

> dependency versions being fixed is a feature Pushing multiple versions of the same library is a bug. Semver ranges exist for a reason. > a dependency published a semver-compatible update that broke something The same can happen with your direct dependencies too. Just use a lockfile and only update it when the install is successful. > In a web context this would break the app Absolutely not. Use lockfiles. Nothing b…

Yeah I missed that the article was only talking about libraries, I was thinking about client code. Agreed it's not an issue for library/server code.

Re: You may not need a bundler for your NPM library

#25

Post by andreareina »

_ZeD_ wrote: post #11
andreareina wrote: post #8

- bundles let you ship less code (tree shaking) - dependency versions being fixed is a feature. I've had package installs fail because a dependency published a semver-compatible update that broke something. In a web context this would break the app until the dependency pulled the update or the dependent pushed an update disallowing that version.

> - bundles let you ship less code (tree shaking) bundling should be done as a step to build an application. it's really not needed when you prepare a library. > - dependency versions being fixed is a feature. I've had package installs fail because a dependency published a semver-compatible update that broke something. If this is the case please open a bug to the dependency team. And then avoid ^ ~ and * in the depen…

I missed that the article was talking about server/library code, I had client/application code on the brain.

Re: You may not need a bundler for your NPM library

#26

Post by johnnypangs »

creatonez wrote: post #16

Huh, is bundling commonly found in library npm packages? Which packages do this? Asking so I can avoid this. I already have a bundle intended for distribution to web browsers, I don't need these sorts of poor practices introducing unnecessary bundling code. Nested bundling sounds like insanity to me. So I very much agree with the author that this practice never made sense in the first place, and I'm baffled that it e…

I think a lot of them use bundlers but they use them for transpiling, going from ts to js and creating esm and common js files not for bundling in dependencies. I’ve also seen bundlers be used to include css in js as to not require users to manually import it.

It’s not so bad, working with just tsc can be a little more cumbersome as you have to running it multiple times to get esm and common js and it’s slower than some alternatives. I see it more akin to using a makefile than an anti pattern.

Re: You may not need a bundler for your NPM library

#27

Post by ItsTooMuch »

KronisLV wrote: post #15
duttonw wrote: post #3

Nice write up. It still boggles the mind when coming from a Java background how things change but also get worse. Having zip's (.jar/.war) which had the source and compiled artefacts available and not cluttering the OS with unzip items. I've run into huge issues dealing with deployments to AWS Lambda nodejs, where the previous developer could not work out how to make a 'slip' deployment and just zipped the whole fold…

> just zipped the whole folder node_modules and all and shipped that I mean, in a sense, something similar is what you should do if you're aiming for maximum reproducibility, of course, excluding the things that you don't need. For a comparison, if you wanted to build a Docker container, it's going to include the node_modules folder in it, instead of installing dependencies on startup. So, in a word, somewhat similar…

Hmm, why don't you specify your development-time dependencies as devDependencies in your package.json? Then you can simply install only the production ones in your final step Docker image - and only use the devDependencies in your build step. I'm doing it, works like a charm. It'd be really weird and wasteful to ship my TypeScript and Eslint and whatever to cloud/Lambda/...

Re: You may not need a bundler for your NPM library

#28

Post by davidmurdoch »

creatonez wrote: post #18
davidmurdoch wrote: post #4

> If you are bundling dependencies, you are not allowing people to get updates to your sub-dependencies with semver! That's a reason for bundling.

So... set ourselves up for another Log4j situation where a vulnerability is found in a sub-sub-sub dependency of some dependency you didn't even know you were using, such that only good way of fixing it is to manually scrub the code from `.jar`s?

Or wait a few days for a patch to be released.

Re: You may not need a bundler for your NPM library

#29

Post by davidmurdoch »

laundermaf wrote: post #19
davidmurdoch wrote: post #4

> If you are bundling dependencies, you are not allowing people to get updates to your sub-dependencies with semver! That's a reason for bundling.

You missed the point of Node’s dependency resolution. If you want to lock the dependencies, just use a lockfile in your app, you don't need to ship the same code 10 times because your dependencies already decided to bundle their sub-dependencies.

No, I understand, I just don't trust semver.

Node package managers don't agree on lock file formats, and yarn doesn't read dependency lock files at all.

Post reply on HN