Preact CLI buy-in

[lwakefield]

I am curious about the future of preact-cli. I have been experimenting with a couple of projects, each of which I have run into some issues.

One example is supporting async/await and the required tweaks needed to .babelrc, which I believe #56 will solve. Another example is some tweaks I would like to make to the prerender.js. But both of these are opinionated changes. These are not changes that I would expect to be included in preact-cli.

As far as I can tell, to make these changes, I either need to wait for updates to preact-cli or fork preact-cli for opinionated changes.

I think both of these problems could be addressed by moving config / build scripts into the project that preact-cli generates (vue-cli does this). I have been watching #56 (much ❤️ for contributors) however I worry that this will increase the cost of buy-in of working with preact-cli.

I think the suggestion made here is an interesting option (clone templates from a repo). Here are some thoughts around this:

• I would imagine this would address a lot of the buy-in issues
• PWAs are the main focus, adding template repos might make it harder to support PWA by default
• If a template repo updates, I would expect it be harder to update code generated from that template. I think this is a good argument for buy-in

Anyway, sorry for the opinions. Much ❤️ for the project!

[developit]

I am 100% in favor of opening up templates to address these issues. The only constraint I place on these efforts is that the defaults need to remain a streamlined and updatable implementation of best practices. That is the main issue i have with scaffolding configuration rather than housing it within the CLI - it makes updates impossible.

For some context, we've had an opinionated CLI around Preact where I work for around a year and a half. It's gone through 13 major versions, yet none of our projects have needed to be reinitialized or re-setup as a result - the configuration is housed entirely within the CLI tool, but can be mutated by passing arguments to the CLI, which enables a high degree of backwards compatibility.

I think a combination of .babelrc support and custom configuration seems like the best option here: Preact CLI will provide all the Webpack wrapping goodness (cleaned output, built-in sensible defaults, etc), and then anyone is free to mutate that configuration as they please. At that point your configuration (mutator) is only tied to Webpack. I'd like to also provide utilities for manipulating configuration in a maintainable way (eg: utilities for finding and adding options to loaders/plugins instead of manually).

So your points are all very valid and things I've been pondering as well. There's a balance here, and so far we've been quite far on the side of "just works" and "updatable", and haven't done much to address the other side of "configurable" and "scalable".

FWIW I am working on a few projects right now that I intend to convert over to Preact CLI once we've released a version that allows configuration extension.

[lwakefield]

Right now, my impression is that without the buy-in you lose the ability to easily make updates. However, I think the buy-in with #56 probably addresses most of the issues that I have with customizability.

With the buy-in, I wonder if there would exist a point where projects which were initialized with preact create mature to a point where they wish to no longer depend on preact-cli. At this point, I don't think it is relevant, but perhaps worth keeping in mind whenever increasing the buy-in to preact-cli.

[happy to close issue, excited for #56]

[developit]

I think that's where things like Create React App allow "ejecting", which I'm open to but would represent a bit of work. Perhaps being able to export the current webpack configuration but then losing out on some of the CLI niceties would be okay though.

If you're good to close I think we can consolidate under #56.

[lukeed]

IMO, the eject from CRA never made sense. Once you do so, you completely detach from a build config & are on your own to guess what was provided inside CRA and/or run with a customized setup.

I'm not necessarily advocating for an eject-type, but if we were, I think it makes most sense to "stamp" out a webpack.config.js into the project's root, so that the user at least has an idea of what they had to begin with. And then if you truly want to sever all ties, it's not a big chore to delete a single file.

[lwakefield]

@lukeed I am not super familiar with CRA. However, it makes sense to me that ejecting should output a webpack.config.js and .babelrc along with anything else in preact-cli src that is needed, ie. components, lib and resources and maybe even commands.

[lukeed]

I just double-checked -- it looks like it's been a long time since I've used CRA. 😅

Their eject now does what we've described: Converting to a Custom Setup

[developit]

Yup. It might not be identical to the built-in config (loaders missing maybe) but it should be the same build output.