RFC: Preact CLI

Preact currently offers great compatibility with the rest of the CLI tools offered by the React ecosystem. These include nwb, which exposes Preact scaffolding and flags for build-time switching to Preact and create-react-app which you can mostly drop Preact into.

Increasingly, with folks seeing preact-compat as a stepping-stone into using Preact and more than just a drop-in for better loading perf than React in production, there are opportunities for Preact to define it’s own CLI with Preact ecosystem best-practices. I see great opportunities for providing a “fast-by-default”, zero-config experience out of the box ⚡️

Something that encodes:

• Minimal scaffolding with a verifiable performance baseline 🏠
• Minimal unit testing setup (c-r-a uses Jest) ⚒
• Minimal prescribed application/directory structure 📁
• Upgrade/Migration-friendly (similar to how c-r-a delegates this out to react-scripts) 🏃
• Optionally prescribed minimal add-ons like preact-router
• Pre-configured Webpack 2.x build. VueJS does an excellent job of this for both dev and prod.
• Perf best practices, defaulting to things like code-splitting ✂️ (we’re pushing for this in create-react-app too), link rel=“preload” and maybe even Service Worker support (e.g support via sw-precache-webpack-plugin or offline-plugin) for Progressive Web Apps (as we documented here).
• Depending on how brave we are, we could even aim for every app scaffolded and prod-built by preact-cli to be a PWA by default 🥇 (the Service Worker caching would help with instant repeat visit perf on both desktop and mobile. Also opts you into V8’s code-caching earlier).
• Given Preact’s focus on size and performance, it could even use the Webpack performance budgeting feature to help folks keep their app size under check.
• Something that supports create-react-app’s awesome eject feature

A common question we might get is “Why does Preact need it’s own CLI? Why not just continue using create-react-app?”. My view is that as much as possible, c-r-a are open to baking in ideas like performance best practices out of the box, but are going to need to balance that with DX and beginner-friendliness. I feel like Preact is targeting a more performance savy audience and this gives us opportunities to explore this space a little more ambitiously.

Like, what if Preact even baked in ideas like PRPL for you? or could intelligently help you figure out what needs to be prefetched. This might be out of scope, but just throwing ideas out there to see if there would be interest in something like this 😄

PRPL support becomes a lot easier to automate once you know the directory structure. We could potentially take inspiration from Next.js’s pages/ and introduce a routes/ directory that gets paired with bundle-loader?async in there.

Thoughts welcome! I’m approaching thinking of this through a browser vendor’s perspective (perf) but there are probably other takes and ideas folks will have on what this might look like.

[developit]

https://github.com/developit/preact-cli

[addyosmani]

Quick update: we’ve started work on the CLI and @developit is going to noodle on some prototypes. I’m sponsoring via OpenCollective as we ❤️ Preact and would love to see it lower the friction for folks building PWAs.

The current plan is to try building Preact CLI on top of the work @ev1stensberg is doing for Webpack CLI. See how far we can get.