Devlog: npm package publishing + going all-in on ESM #87
dtinth
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We are revamping the Creatorsgarten website, and this means there will be a lot of changes to the wiki engine to accomodate the website. This means to move fast we must become leaner.
As of writing, Contentsgarten is designed to be easily integrated with popular application frameworks. To prove that the core is framework agnostic, we run 3 websites with Contentsgarten, each site using a different framework. As of commit 7778a3b:
What we’ve learned is in order to integrate with all these frameworks, an unhealthy amount of workaround had to be done.
For Remix, due to its lack of native support for ES modules when bundling, we had to ship a CommonJS version of Contentsgarten just to make it functional in Remix.
For Next.js, due to it hijacking the fetch API, it resulted in a lot of problems with stale data. I have to spend a lot of time learning the idiosyncrasy of Next.js’ caching system. Although it was a great learning experience (I have a much better understanding of how Next.js caching works in the new
appdirectory, and gained an appreciation of how it makes making it easier to build performant sites), for newcomers, the surprising behaviors exhibited makes the codebase harder to contribute (sometimes it keeps caching things I don’t want cached, and I spent an hour figuring out the settings to make it caches the way I want it to).Astro is least painful because it embraces native ESM as a first class citizen which aligns with the project’s goal to use modern JavaScript. Therefore here’s what going to happen
contentsgarten-cjsmodule will be deleted.The Contentsgarten Wiki will be re-written to be based on Astro.Workaround found!wonderful.softwarewiki, we will use Next.js, but not RSC. (SSR is enough.)npmIn summary:
Beta Was this translation helpful? Give feedback.
All reactions