Switch from Webpack to Parcel for documentation site

[macklinu]

Hey @lowmess 👋 I was using this library the other week and started poking around at the source / documentation site. I was curious to switch things from Webpack to Parcel to see if that would make the site easier to build / contribute to, mostly out of curiosity. Thought I'd PR this to see if you're interested in this change (no pressure either way).

Overview of the changes:

• remove all Webpack config and swap out for Parcel. What's nice about Parcel is that it uses HTML files as an entry point, so you can say parcel src/index.html, and if Parcel finds any dependencies in that HTML file (like src/main.js), it'll compile and bundle that code for you without any configuration. 😄
• use babel-plugin-preval to generates the colors.json instead of having a separate prebuild step. This will effectively run the same color combos function at build time but uses the Babel build pipeline to generate this code instead of an explicit Node.js script. This removes two prebuild scripts in www/package.json.
• updated from Babel 6 to Babel 7

To test things locally:

• checkout this branch
• cd www and yarn to install new dependencies for the documentation site
• run yarn start to preview the documentation site at http://localhost:1234
• kill the server and run yarn build:min to generate a production bundle (output to www/public)

[lowmess]

@macklinu Dude this rocks! I'm a big fan of the idea of switching to Parcel, it's a tool I want to start using more for projects exactly like this. There is one problem i'm noticing though, which is that the production script is using the obfuscated function names for the hover states. You can see it in the deploy preview. I'm sure there's a way around this, but I won't have time to find it for at least a few days. Also, thank you for bringing my attention to preval! Insanely helpful tool.

[macklinu]

I’ll take a look at that issue, thanks for pointing that out 👌

[macklinu]

I think 4635f74 should fix the issue you were seeing by generating code documentation from the string name of the function (now passed into markup()), instead of using Function.prototype.name, which looks to get mangled by Parcel when minifying code for production.

One other thing that might be nice is to add a Parcel plugin to clean the output directory before building. I noticed that successive every time I ran yarn build after changing code, I would end up with another set of bundles added to the public/ directory:

public/index.html will point to the right assets, but there's probably no need to have all of those extra files around. Will push a commit to address that, but I think from a code functionality standpoint, this PR is ready to review again in the Netlify preview.

[macklinu]

Addressed cleaning the output directory before building in 1741c12. 👍

[lowmess]

@macklinu I updated the markup function to add the spaces back in to the pattern names. I also realized that the text was breaking out of the swatches at certain breakpoints. This was because the custom breakpoints set in main.css were no longer being used (there's an upstream Parcel issue about postcss-import not working properly). So I also refactored the main swatch layout to use CSS grid. I also did some small cleanup while I was rooting around in there. I'm gonna take a second look when I wake up in the AM but I think this is good to go!

[macklinu]

Thanks for fixing some issues I introduced in those changes. 😅

Curious what you think about this experiment (Webpack -> Parcel). For me, it was a little more error prone in ways I didn't expect, but there is less configuration, I think, so maybe a net win? 🤷‍♂️ Definitely points out some things that could be improved in Parcel (like that postcss issue you mentioned).

[lowmess]

I'm a really really big fan of Parcel's philosophy, but it definitely has some tradeoffs for DX. Like the postcss-import issue is really surprising to me, because it's one of the most used (~1.5 million weekly downloads!) and most useful plugins out there. Another small thing that really surprised me was the console output, I would have preferred a bit more information -- timestamps, maybe bundle size or something.

But! This switch reduced the page weight by like 55%, which is magic.

Anyhow, merged! Thanks so much for this.