parcel

G IMAGE ID CREATED SIZE localhost/node latest a28f38037137 6 seconds ago 93.5 MB localhost/base latest b593261330c1 5 minutes ago 30.5 MB Assuming dependency management was equal level of maintenance with Node, the spirit of Node ecosystem tends accept being whimsical with breaking changes. Terser or whatever Node-based processing library will introduce breaking changes to their config in relatively small timescales ( months, years, instead of decades ). That's not inherently a technical fault of the ecosystem as it is a cultural one. The popularity of JavaScript is its own undoing. Opting for tools in other web-friendly languages selects for a different type of developer. That's just for minification. Want to inline CSS? That sed command is 66 characters long. That's about the same as Parcel's zero-config config boilerplate that is NoOp: https://parceljs.org/features/plugins/. Surely a WebPack config is more than 66 bytes. I proceeded to add Parcel to compare how much it increases the image size, unfortunately it failed because there is a Python dependency: └─ ▶ echo 'RUN npm i parcel' >> Containerfile && podman build -t parcel . [2/2] STEP 18/18: RUN npm i parcel npm WARN deprecated stable@0.1.8: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/A… npm ERR! code 1 npm ERR! path /usr/share/nginx/html/node_modules/@parcel/watcher npm ERR! command failed npm ERR! command sh -c node-gyp-build npm ERR! gyp info it worked if it ends with ok npm ERR! gyp info using node-gyp@9.0.0 npm ERR! gyp info using node@18.2.0 | linux | arm64 npm ERR! gyp ERR! find Python Fine, I added Python, Make, and other transitive dependencies to see how deep this rabbit hole goes: └─ ▶ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/python latest 05582c8b2425 2 minutes ago 156 MB Will Parcel installation work now? Nope, here's the new error trace: https://gitlab.com/-/snippets/2364041. It appears this is a dependency issue with Parcel, Maybe?, with this similar 6 week old thread: https://github.com/parcel-bundler/parcel/issues/8152, which reiterates the painpoint about Node. Let's take a step back and forget the Parcel example for a second. How about NextJS? From that 30mb Alpine base image: ```Containerfile RUN apk add npm && npm i next react react-dom └─ ▶ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/nextjs latest d177ee032ff0 9 seconds ago 266 MB Kudos to NextJS for installing properly at least, but that single command added 266-30mb = 236MB to the image, and this is where the bloat creeps in. Thinking 200MB is a nothingburger is how we end up with gigabytes large images.

and tied up in ribbons and bows for delivery to the user's browser or device. So I did the work of turning my library into an NPM package and tried building a toy project with a toolchain. The failure was embarrassing. It turns out that I was using a JS feature in my library code which isn't supported by any of the main bundlers (`import.meta`, for the curious[2]. I raised a ticket with one of the bundlers to see if they could add support in a future release[3] but it seems the feature is too obscure to care about.) I sorted the problem by rewriting my library (in a very unsatisfactory, ugly way) to get bundlers to bundle the code. Now people can add my library to their React/Svelte/whatever project. But the whole learning episode left a bad taste in my mouth: Being tripped up by Vanilla JS is one thing; having your work trashed by the bundlers in the toolchain is just nasty! [1] - https://scrawl-v8.rikweb.org.uk/ [2] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [3] - https://github.com/parcel-bundler/parcel/issues/3269

rather. The workaround was throwing an Error in the hot reload handler.