First attempt at adopting Parcel #1186
Conversation
✅ Deploy Preview for vigorous-lalande-5190c2 canceled.
|
|
Size Change: -459 kB (removed) 🏆 Total Size: 0 B
|
| "jest": "^27.5.1", | ||
| "prettier": "^2.3.2" | ||
| "prettier": "^2.3.2", | ||
| "stream-browserify": "^3.0.0" |
There was a problem hiding this comment.
Where did all of these changes come from?
There was a problem hiding this comment.
If there is some import to a Node builtin modul (e.g. stream), Parcel autoinstalls the corresponding polyfill.
There was a problem hiding this comment.
(And same goes for the two Parcel plugins listed in here, which are installed on demand. And in this case, you forgot the bump them when upgrading to "parcel": "^2.8.2")
There was a problem hiding this comment.
Oh awesome! I assumed it was something like this, thanks for commenting.
BTW, shipping this is currently blocked on some significant size regressions. Webamp lazy is the simpler case to debug since it doesn't pull in some of the heavy dependencies like JSZip.
Using the bundle analyzer reporter gives a nice looking report, but it's dominated by "code from unknown sources". So my next step is to try to figure out what's contributing to this regression.
https://enchanting-khapse-0a90c1.netlify.app/webamp-lazy.html
If you happen to have any tips on how to diagnose, that'd be super helpful!
There was a problem hiding this comment.
"isLibrary": true makes the default "optimize": false, because you usually don't want published libraries to be minified. But you can override that of course (I assume you want minification as they're called *.min.js?):
--- packages/webamp/package.json
+++ packages/webamp/package.json
@@ -15,7 +15,8 @@
"webamp": {
"source": "js/webamp.js",
"outputFormat": "esmodule",
- "isLibrary": true
+ "isLibrary": true,
+ "optimize": true
},
"webamp-browser": {
"source": "js/webampBrowser.js",
@@ -24,7 +25,8 @@
"webamp-lazy": {
"source": "js/webampLazy.tsx",
"outputFormat": "esmodule",
- "isLibrary": true
+ "isLibrary": true,
+ "optimize": true
},
"demo-site": {
"source": "demo/index.html"
@@ -36,7 +38,7 @@There was a problem hiding this comment.
Okay. It looks like the remaining difference for the lazy version is entirely attributable to the fact that I haven't yet ported my image optimization to Parcel.
I tried manually checking the optimized version of the CSS into the repo and we are now at ~3% reduction in bundle size!
Reading the Parcel docs it implies that png images are automatically optimized. It looks like that does not apply to png images that exist as data uris in CSS files (that's what my custom Webpack loader does). Is that an optimization that Parcel could/should apply? It seems in keeping with Parcel's approach of automatically applying optimizations where it can, but I also get that this is quite an edge case.
There was a problem hiding this comment.
🎉
Is that an optimization that Parcel could/should apply? I also get that this is quite an edge case.
Yeah, but it should be possible to support in Parcel.
An alternative here (and this might even be preferable just from a code authoring perspective) is putting these inline PNGs into separate files and then using Parcel's feature to inline it as a data-url: https://parceljs.org/features/bundle-inlining/#inlining-as-a-data-url
There was a problem hiding this comment.
Yeah, I think a "normal" app would work this way, but Webamp has built in support for loading custom "skins", which means it converts the zip file into CSS (with embedded data uris) in the browser. The way I generate the default skin CSS file is I load the custom skin and copy out the generated CSS. This means there's not a reasonable way to get those (probably hundreds) of png files as actual files on the file system.
There was a problem hiding this comment.
As you saw, I raised the issue on the Parcel repo: parcel-bundler/parcel#8758 (comment)
I'll probably just keep my existing setup unless that feature looks appealing to someone to implement.
There was a problem hiding this comment.
I'll see if I can fix that parcel issue you mentioned -- I'll recomment here if I get to it.
Still a number of things to get working:
Build UMD build(s)
Ensure files are included in npm release
Ensure Netlify deploy will work
Optional