I love JS, but every once in a while a new bundler comes along that "solves everything". And it works, for a while. then it breaks. Why? Why are there so many edge cases? I don't understand it. We only have a few module types (AMD, CommonJS, ES modules), with a few types of import and export syntax. How hard can it be to get it always right?
Like parcel. It worked. For a while. And now if you check the GitHub there's 690 open issues, and I had issues today getting it to work when running after an 'npm i' done in v17 or v18, yet it's fine to run in v{16,17,18} if 'npm i' is done in v16.
And snowpack: v0 (or 1) worked great, but the next version broke so many things (compared to the prior version) that I need to keep the dep version locked to the earliest ones for packages where I use that. Tho I guess that's more of an API problem.
What I'm really talking about is: why can't we just have a bundler that works always and everywhere (and I don't want to 'wait for' deno)?
Why would parcel start to get bugs...how hard can it be??? :...(
Comments URL: https://news.ycombinator.com/item?id=33142840
Points: 7
# Comments: 1
Continue reading...
Like parcel. It worked. For a while. And now if you check the GitHub there's 690 open issues, and I had issues today getting it to work when running after an 'npm i' done in v17 or v18, yet it's fine to run in v{16,17,18} if 'npm i' is done in v16.
And snowpack: v0 (or 1) worked great, but the next version broke so many things (compared to the prior version) that I need to keep the dep version locked to the earliest ones for packages where I use that. Tho I guess that's more of an API problem.
What I'm really talking about is: why can't we just have a bundler that works always and everywhere (and I don't want to 'wait for' deno)?
Why would parcel start to get bugs...how hard can it be??? :...(
Comments URL: https://news.ycombinator.com/item?id=33142840
Points: 7
# Comments: 1
Continue reading...
