Hey, to explain the missing version bump: The commit is there, it just didn't land on master. I've now pushed it (same for inlineresources yesterday).

Can I ask you what the pain is that you are solving here?

^1.2.0 should like ^1.1.0 always install the latest version as long as it starts with the major version "1"? So I don't see the point of releasing another version here. I might be missing something?

Can I ask you what the pain is that you are solving here?

^1.2.0 should like ^1.1.0 always install the latest version as long as it starts with the major version "1"? So I don't see the point of releasing another version here. I might be missing something?

My reasoning is that inlineresources had a bug, so I wanted to ensure we depend on a version that doesn't have that bug.
Users should be able to do npm install inlineresources@1.2.0 if they want to upgrade the problematic dependency, but it would be nice if rasterizehtml would already provide the correct version range.

Not a big deal, though, so feel free to close this PR.

No I understand.

If I install rasterizehtml from scratch locally I seem to get the newest version though. That is what you want I understand?

/tmp $ npm i rasterizehtml

added 26 packages in 832ms

11 packages are looking for funding
  run `npm fund` for details
/tmp $ head node_modules/inlineresources/dist/inlineresources.allinone.js
/*! inlineresources - v1.2.0 - 2026-01-12
...

What you of course don't have is the right version in the allinone bundle. I should've stated that earlier.
I was somewhat neglecting that because I hope we could slowly get rid of this? How far has the community come on easily consuming transitive dependencies? I haven't set up a greenfield JS project in a while.

If I install rasterizehtml from scratch locally I seem to get the newest version though. That is what you want I understand?

Yeah, but if you already had v1.1.0 on your lockfile, it will keep installing v1.1.0 unless you explicitly install v1.2.0.

What you of course don't have is the right version in the allinone bundle.

Yeah, forgot to mention that as well.

I was somewhat neglecting that because I hope we could slowly get rid of this? How far has the community come on easily consuming transitive dependencies? I haven't set up a greenfield JS project in a while.

As far as I understand, it isn't common to bundle a libraries' dependencies when publishing. It prevents reusing dependencies (e.g., some other library might accept the same version of inlineresources, but since it's bundled, the code is duplicated), and it could also make dead code elimination more difficult.

In my opinion, it would make sense to remove the all in one bundle. It would probably also ease the migration to more modern build tools.

If you agree, I can try to tackle it.

Alright, released another version with your changes!

If you have time, feel free to provide a new major version without the all-in-one bundle.

I've tried updating some of the test dependencies, but it is at least non-trivial.

Thank you! I'll try to tackle it when I have some time 👍