Having tslib as dev dependency is inherently weird. Maybe they meant it to be dev dependency because the resulting bundle doesn't depend on anything from node_modules, but this way we could say that any dependency is dev dependency

@Laurențiu Nicola well rollup was published 5 years ago and webpack 8 years ago. I am not sure wether this is the new better guy on the market, I am just following the trends )https://www.npmtrends.com/rollup-vs-webpack

I just read the blurb, it says "next-generation" :grinning:

I wonder if anyone is working on Code bindings for Rust

Speaking about "next-generation" I heard that initially webpack was a very good piece of software, it got popularity, but somehow its maintainers didn't support it very much and that's why new bundlers (maybe rollup was one of them) appeared. However after some time webpack maintainers caught up and started developing it very much to the state that it is now dominating the market.

And of course I can't place a comment into package.json to explain this weirdness

FWIW, the "//": key is reserved for comments in package.json. Feels a bit kludgy to use that though :sweat_smile:

and on the topic of webpack vs. rollup, general consensus I've heard is that the former is better for applications, the latter is better for libraries. If you're literally just bundling your JS rather than doing anything fancy, I'd definitely recommend avoiding the hassle of maintaining a Webpack config file :grimacing:

@std::Veetaha btw the today's morning problem, "build works via rollup, but not via build task" is exactly an issue which wouldn't be caught by an end-to-end test. It seems like you should just suffer through similar things :-(

But my point is that, for integration, things usually break in a pretty surprising ways, which are not tested. Like, after every specific failure you can add a test that will catch this specific failure, but the probability that it won't catch the next failure is pretty high