PROPOSAL: single-spa CLI about single-spa

[joeldenning]

After discussing this further with Milan during the monthly core team meeting, we've decided to proceed with a proposal and proof of concept for it. In 2024, we probably need to simplify the DX to be able to be viable compared to alternatives, even though I don't like hiding configuration

[ibacher]

I agree that the amount of configuration exposed via create-single-spa may be overwhelming to beginners and there's some low-hanging fruit that can be done there. I'd want to know a little bit more about the scope of the proposed "Advanced Customization"; I'm not really familiar with NestJS, but this seems like the area where the tooling is most likely to get a bit out of hand.

[MilanKovacic]

By default, the development script could be something like:

"start:dev": "single-spa build" (which would use a default single-spa managed webpack configuration)

For projects requiring changes to webpack configuration, they could do something like:

"start:dev": "single-spa build --webpack-configuration custom-webpack-configuration.js"

Where we would then inject internal webpack configuration, and allow customers to customize, it similar to:

https://docs.nestjs.com/recipes/hot-reload#configuration

Some examples:

https://docs.nestjs.com/cli/overview
https://nextjs.org/docs/pages/api-reference/next-cli
https://docs.astro.build/en/reference/cli-reference/

[joeldenning]

I'm pretty hesitant about going down the path of Angular / Vite / Next / etc where they hide the bundler config, lint config, test config, etc etc within node_modules.

I'm open to a single-spa command that encompasses more than just the npm init single-spa that is currently supported via create-single-spa, but would want to discuss exactly which commands are supported and the implications for existing and new users.

Managing bundler configuration within node_modules is tempting, but I've been in the node_modules bundler configs for single-spa contracting consultants enough to know that we should be cautious about it. Surfacing configuration to single-spa end users is a good thing. I would prefer code mods updating the configuration in many cases, rather than upgrading an npm package that is hiding dozens of configuration files. The Angular way of burying configuration was so horrible to integrate with single-spa - it will be hard to convince me to go down the same path.

JS devs in 2024 are past JS fatigue into "can AI do my job for me" and so there are fewer developers willing to go read webpack documentation than in the past. We should seek an improved DX for single-spa users, but I'd prefer not discarding the current userbase's way of doing things and also would prefer letting users manage the raw configuration rather than constantly opening github issues on single-spa CLI to be able to change their jest configs.

[alex-enchi]

While I agree that cli would be nice for fresh projects but hiding configuration means much harder time for existing projects to migrate. Is it possible to have a cli tool but keep minimal configuration as visible as possible?

I’m quite reluctant to add another cli tool into the toolchain