v4

[rschristian]

Summary

Closes #1551, #1579, #1643, #1747

Tracking for eventual major version increase

Any review should probably been done by stepping through individual commits / their PRs. Each PR should contain the justification for the change and whatnot. A lot of things build off each other, so I've been merging them in here to continue with work.

Lotta rebasing went into this, hopefully the changes are all quite clean because of it.

Does this PR introduce a breaking change?

Yes, see changesets (some still need to be fleshed out a bit though) for details

[changeset-bot]

🦋 Changeset detected

Latest commit: 78e7e9d

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

[rschristian]

Changes that I've thought of, maybe should be considered:

• 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 though ProvidePlugin will do that automatically on build)
• 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.
• --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)
• --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)
• --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.
• 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: RFC: Custom Prerendering / SSR #1108, On Demand Pre-Render #1456, Pre rendering very slow and memory expensive #1463, RFC: Experimental Fast renderer #1482, [WIP] Experimental prerenderer #1501, Idea: Next Style SSR rendering with almost zero effort #1684
• 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 like isDev or isServer 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.
• 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 to html-webpack-plugin v4, both became considerably simpler and so I think it's time to move them into the template, and rename it to template.ejs (but continue to support template.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.

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