Release notes:

• Features
  • Added workspaces to Gleamy’s main repository
  • Supplied development environment with NextJS
• Bugfixes
  • Server-side-rendering is now supported.
    • Note: It obviously still runs on client-side, but it will no longer requires the developer to manually load Gleamy client-side only.
• Other things
  • Refactored the complete compilation set-up to use: NPM, Rollup, TypeScript, NextJS, ESLint, Prettier and React
  • Pipeline added for daily NPM package auditing, on top of a weekly Snyk report
  • Compiled the license-file into the source code
  • Provided the .md files into npm-tarball

Why we released these changes

Greetings! In our previous blog post, titled “The Gleamy Chronicles: Unveiling the Enigma of Our Update Hiatus” we discussed the factors contributing to Gleamy’s delayed update. In summary, the features we discussed were in the pipeline and making progress. However, the process of creating these updates has proven to be quite challenging. Tasks such as linking packages, updating the primary website (the component editor), and addressing performance issues have slowed us down. Even after allocating more time to the previously announced update, we concluded that it still wasn’t up to our standards.±

Furthermore, it has been a hectic few weeks with Bun announcing its all-in-one solution for everything. We gave it a try, and to cut a long story short, it didn’t align with Gleamy’s current needs. While it did deliver the promised speed, we thoroughly explored its compatibility with Gleamy.

In the end, instead of relying on tools like Yarn, PNPM, Vite, Webpack, and others, we decided to take a step back and concentrate on what truly mattered:

• Implementing workspaces to segregate the development environment and future updates.
• Focusing on Gleamy and potentially porting it to different platforms.
• Creating a robust development environment.
• Employing a stable package manager.
• Having a clear understanding of how everything is interconnected.

This led us to eschew modern tooling that claims to do it all and return to the technologies that initially laid the foundation. We turned to NPM as our package manager, managing workspaces, TypeScript as the compiler, NPM Workspaces (as other package managers required different configurations), Rollup for bundling according to our preferences, ESLint and Prettier for maintaining code style and quality, Jest and React testing library for unit testing. Last but not least, we chose NextJS as the development environment to not only run a web server but also focus on server-side rendering.

We realized that this approach makes the most sense. It served as a reminder that stable technologies, while they may not always boast the speed or features of newer setups, consistently deliver as expected without deviating from community standards. We sometimes forget that they also evolve and improve, rather than merely chasing the latest trends. While new tools are undoubtedly exciting and efficient, they often lead to redundant solutions and increased complexity. As challenging as manually tying everything together can be at times, it maintains transparency. This, in turn, makes it easier to refactor in the future and stay ahead of security concerns.