Build tools

One of the things that blocks the development of Gleamy is the proper build stack. For Gleamy, a simple stack with NPM, TypeScript and Rollup has been chosen in order to get things done. While this stack is perfectly fine, it still isn’t a great developer experience.

For instance; when the repository is checked out, and you want to start the development environment, you first need to build Gleamy. And for each update… well, you need to build Gleamy. So there’s a lot of hassle in getting it to work. Especially when you want to improve performance, or start refactoring, it is a painful process.

Most likely, Gleamy is moving to a stack using PNPM and TurboRepo. It integrates nicely with NextJS as development environment and deploying to Vercel as this is the website’s hosting provider. It also solves most of the issues.

The big movement: Web components

Gleamy started off as a React project where it would be easier to integrate some more effects to your website. But Gleamy should be available for anyone who wants to add some glamour to their websites or web-apps. As Web-components are now more developed, and perfectly usable within other frameworks and libraries like Angular, Vue and React, but more important: native/’vanilla’ as well. So Gleamy could be added as a WordPress plugin as well, or better integrated in a theme without having the overhead of shipping with proprietary code.

A bigger mono-repo

Whilst it would be great to have single repositories, it will be a hassle to plan and release each-part separate. So Gleamy is going towards a more separated mono-repo, where more rigid test set-ups can be made, better separations. So can ship TypeScript definitions, without adding this to let’s say, a native JavaScript bundle. Each release will be working on all platforms, when built.

Configurator included

One of the handiest tools to develop Gleamy is with it’s own configurator that you can find on the website. In order to not lag behind and actually use and tweak the code, it makes sense that the code for this will be in the mono-repo as well. Because of its complexity, and sometimes, more work than developing Gleamy itself, getting everything on the same code-quality as Gleamy is a bit of work. So moving this tool here will be slow.

Package deployement

While all Gleamy packages will be deployed on NPM, there are a couple of things that will change;

• Packages will fall under an organisational structure on NPM
  Gleamy is currently a React library, and can be found under a base route within the NPM site /pacakge/gleamy. When Gleamy will become web-components, it makes no sense to use the default url for React. So Gleamy will move these new packages to its own organisational structure on NPM.

NPM/JSR/TypeScript, ESModules, CommonJS?

One of the things that come up in conversations a lot is how realistic it is to keep to the set-up of deploying all code, packed with both CommonJS and ESModules, including typescript definitions.

This is still something that has to be decided on. While no one wants to add a lot of dependancies in projects, and bloating with various unused code, it cannot continue without thinking about the set-up. What is still preferred? what is the standard? what direction are we going on short, but also long term?

Conclusion

Gleamy for sure needs to change in order to make development, integration and developer experience better. And it’s going to happen. But it will take some time.