Scaffolding CLI / next steps

[jonaskuske]

Okay so I know this is a PoC right now, but I really like this idea and would be interested in taking it a step further :)

This would mean:

• Publishing a basic CLI so one can npx create-esm-react-app ⚙
• Making the default project "production-ready" (for evergreen browsers). That means dropping code-splitting with import() (or rather making it opt-in, see next point) because of browser support and providing some sensible ESM-compatible defaults for styling and routing, as mentioned in the README already. 🚀
• Since we don't run any tooling, the CLI could be really simple. Collect some options (Use code splitting with import()? y/N, Use service worker for offline caching? y/N, ...), then scaffold the project and done. 🏗
• Since we don't have a build step and are not transpiling with Babel, I'd suggest automatically creating a .browserslistrc based on the scaffolded project and adding an eslint config with eslint-plugin-compat so users get warnings if they use features not available in all major ESM-equipped browsers. ⚠ And if the config files are already too much "build tooling", we can at least recommend it in the docs :)
• And of course, docs. Covering both usage of this tool as well as what's generally required for a proper ESM setup, e.g. HTTP2 w/ Server Push highly recommended 📃

What do you think about this?

[lukejacksonn]

I think a lot of this sounds fantastic! To address your points:

• A basic CLI was my next goal this npx create-es-react-app should be a thing. Also programatic creation of components (with styles) and routes would be nice. The script could live in this repo but I'd like to keep it dependency free. Have you ever done anything like this before?

• Right now I'm not focussed on supporting browsers that haven't kept up with the times. It is a real shame Firefox don't support dynamic import. I'd prefer to get things setup for the best case scenario first. My plan is to eventually do this kind of "optimisation" at serve time. F or now I would suggest people use a ponyfill for import()

• Config files are kind of against the grain of this project. Not every developer will have eslint-plugin-compat or even be using a linter but useful error messages are good. Maybe PR this and see what it looks like.

• Regards documentation, I would like to extend it first by explaining how to deploy it to GitHub pages. Given that most people using the project will have a GitHub account then recommending this comes at very little cost. We will however have to add a custom 404.html page and perhaps a CNAME file unless we find a router that can be configured with a baseUrl (perhaps navi when this is resolved). It already serves content over http2 and https.