preact-cli
preact-cli copied to clipboard
v4
Summary
Closes #1551, #1579, #1643
Tracking for eventual major version increase
Any review should probably been done by stepping through individual PRs that have been merged in. A lot of things build off each other, so I've been merging them in here to continue with work.
Does this PR introduce a breaking change?
Yes, see changesets (some still need to be fleshed out a bit though) for details
🦋 Changeset detected
Latest commit: 78e7e9dfc0c14a30c538dc55e2ed943da4c4c437
The changes in this PR will be included in the next version bump.
This PR includes changesets to release 4 packages
Name | Type |
---|---|
@preact/async-loader | Major |
preact-cli | Major |
@preact/prerender-data-provider | Major |
create-preact-cli | Major |
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
Changes that I've thought of, maybe should be considered:
- [x] Switching to automatic JSX runtime
- Seems to be the way the community is going these days
- Not sure if this is actually relevant or anyone cares though. I suppose it's nicer for TS users, as the TS language server will yell about
h
not being imported (even thoughProvidePlugin
will do that automatically on build)
- [x] Switching CSS module support to depend on file name, rather than directory
- Some users get tripped up by CSS acting differently in different locations and I do agree that this is unintuitive. I'd therefore like to follow what WMR and Microbundle do and use
.module.css
to determine whether or not CSS should be treated as a module.
- Some users get tripped up by CSS acting differently in different locations and I do agree that this is unintuitive. I'd therefore like to follow what WMR and Microbundle do and use
- [x]
--json
flag- Is this in use? Do people want to use alternative bundle analyzers that often?
- ~~Should rename (or alias) to
--stats
,--json
doesn't make much sense (IMO)~~- Went for removal instead (can revert if desired, not too opinionated either way)
- [x]
--brotli
flag- I think it's fair to leave this up to users, it's a bit niche (though not hard to support if we do want to keep it)
- [x]
--inline-css
->--inlineCss
- Can keep both with an alias, but should be consistent on camelCased or kebab-cased flags in the docs. This is the only kebab at the moment.
- [x] Separate out
create
functionality-
npx
makes this quite slow, which is unfortunate. All dependencies (~1060 of them) will need to be installed for minimal (create
) functionality. Could make new project init quite a bit faster by extracting this out, though that might be annoying tooling-wise. - Opinion, but I think we can really cut this down. I don't think a full interactive CLI app is necessary here. It's just a couple options really.
-
- [ ] Faster prerender
- This seems to be a pretty common complaint at the moment. For reference: #1108, #1456, #1463, #1482, #1501, #1684
- [x] Separate CLI-config from env we pass to users in their
preact.config.js
- We load up
env
with all CLI flags as well as the user's manifests and package files. This info is likely of little to no use, and only buries things likeisDev
orisServer
which is what they're probably looking for. - At the very least we should strip the manifest and pkg data out, users can do a
fs.readFile
if they really need those.
- We load up
- [x] Move
head-end.ejs
&body-end.ejs
into template- There's a lack of transparency due to the way we're replacing
<% preact.headEnd %>
and<% preact.bodyEnd %>
with EJS snippets on build, which is a shame. With the move tohtml-webpack-plugin
v4, both became considerably simpler and so I think it's time to move them into the template, and rename it totemplate.ejs
(but continue to supporttemplate.html
as a fallback). I'd like it to be plain and obvious that this is something for users to configure any which way they need.
- There's a lack of transparency due to the way we're replacing
Templates:
- Kill off widgets, simple, and netlify
- The widgets have never fit in well. I think they're working fine for now, but
preact-cli
is only utilized as a dev server / testing area. It doesn't make much sense to initialize widgets through CLI, IMO. - A couple users have gotten tripped up from simple not showing off important concepts, like route splitting, css modules, and testing.
- I have no capacity to debug netlify issues if any come up
- The widgets have never fit in well. I think they're working fine for now, but