Compatibility list

[marvinhagemeister]

I've been trying out wmr in some existing client projects and I'll use this issue as a list to keep track of changes I had to make. Mostly to be aware how we could ease migration to switch to wmr from another build tool.

• Class components typically use class fields Add support for class fields #126
• Importing image files returns the file path as the default export Add support for importing non-js files #133
• @urql/core import fails. See Unable to import scoped packages like @urql/core #129 and Fix error when file doesn't match package export #139 (PR)
• React projects often have a loader for .svg files, that returns a ReactComponent export
• Node-resolution like /foo -> /foo/index.js, imports without extension basically Add support for node-resolution #138
• Error overlay

[developit]

#3 I don't think should be a default, since there's no standard mechanism for it and a bunch of popular approaches. It would be a great test of configurable plugins though.

What are you thinking for manifest.json? I added a "pwa" fixture that includes one, but there's no tests that use it yet.

Error overlay sounds good. If possible, I would really like to have it be a module that gets imported (import 'error-overlay' or something). It could still import stuff from WMR's client lib if it needs access to internals (HMR does this), just that way WMR avoids being super specific to react/preact/etc by default.

[marvinhagemeister]

@developit regarding the manifest.json just noticed that the spa sites I have access to link to it in their d entry HTML file. Maybe we just need to do it like webpack and only fill that in during production.

Agree about 3) being out of scope for wmr. Once we have a config file and maybe expose or plugin system is easy enough to create a third party plugin.

Yeah the chill thing about it error overlay is that at likely don't need to add sourcemap deciding. When I was working on that for vite (never published) that really made up 80% of the code size.

[marvinhagemeister]

Thinking some more about the manifest.json, I wonder if we should just default to serving an empty json (just an object) during dev. Just so that it doesn't 404. Can't think of a reason why one would need it during dev.

[developit]

Whoop - missed your comment there. Another option would be to suggest what we currently do for favicons, which is an empty data URL: <link rel="manifest" href="data:">. Avoids the 404, though it doesn't really help folks get towards a PWA haha.

[marvinhagemeister]

Like that, anything is better than showing a 404 👍

What are the differences between WMR and preact-cli? Is it that WMR replaces webpack?

[developit]

That's one of the biggest differences, yeah - WMR uses Rollup, and only in production (during development it uses Rollup's plugin API but not Rollup itself). Other than that the design is fairly different - Preact CLI tends to be more prescriptive about things (the src/routes folder, async! prefixes, pre-rendering config file, CSS Modules by default in some directories, etc). WMR is more generic, with the details of things like lazy loading and routing left up to you (though we provide the preact-iso library as a helper).