solidjs / solid-meta

Write meta tags to the document head
127 stars 16 forks source link

Enable using lib with commonjs #3

Closed yonathan06 closed 2 years ago

yonathan06 commented 2 years ago

While working on the integrating SolidJs SSR with fastify-vite, I received errors solid-meta is an ESM so couldn't import it using require(...) on the server side (for rendering tags) wondering if removing "type:module" from package.json will solve it, or maybe we shouldn't use commonjs anymore

ryansolid commented 2 years ago

No, we actually need to compile the JSX for the server version since it compiles differently. Generally this means bundling it as well with vite. If using the Vite plugin is should be looking at the "solid" export condition already: https://github.com/solidjs/solid-meta/blob/main/package.json#L15.

In general there are too many combinatorics in people's app for libraries to assume they can generate all the outputs, so like Svelte/Vue we compile at application build time.

yonathan06 commented 2 years ago

So you suggest to bundle the server code as well before running it when using Commonjs instead of ESM? I see in the server example ESM is used

ryansolid commented 2 years ago

The example uses ESM but the assumption is it needs to be built(or bundled) as there is JSX in there. So the build can output ESM or CJS or whatever is needed. But regardless of whether using ESM or CJS it needs to be transformed.

yonathan06 commented 2 years ago

Still think there can be a benefit for a cjs output, maybe only for the renderTags function that it used in the server. Perhaps something like const { renderTags } = require("solid-meta/server"); because usually we avoid bundling/transforming server side code (not that it will ruin our server, but it is not a common practice like in front end code)

ryansolid commented 2 years ago

There is JSX that is untransformed. Like <MetaProvider> from the same module which is used on the server and is the only thing that accepts renderTags. The only reason there is even an ESM output is for no-build client-only scenarios like using a CDN where people use Tagged Template literals. But hydration needs different output than client-render build so this always needs to be transformed client/server for SSR. Even best case where this happens runtime on the server, like with a require hook still will involve transforming the module.

Pre-building would require up to 16 different bundles for the known configs and discounts the potential of custom setups. I think it is unlikely to be able to avoid transforming on the server.