Project enhancements

[nakrovati]

I have some ideas on how to improve the project.

Ideas to implement:

• Replace NPM with PNPM. When I was upgrading frameworks I used to load esbuild, webpack, rollup and other package used in building frameworks several dozens of times. This will not only save HDD/SSD life, but will also speed up package downloads dozens of times and save internet bandwidth.
• Replace NVM with FNM (speeding up Node.js startup for each of its calls). Also supports .nvmrc.
• Implement Turborepo/Lerna+NX (hard to implement, but just imagine that you run build-prod and lint for 200 packages with 1 command at a time, and then the result of their execution is cached). Now rebuild-*.js scripts are used for this, but they are not efficient (they work of course, but maintaining them in the future is a headache, so it's better to shift this work to the tools I suggested.
• Replace Eslint with Rome or Oxc for server, webdriver-*, and global directories (excluding dinting and formatting for frameworks).
• Replace Express with Fastify. Takes about 4 hours (worst case scenario).
• Implement Husky + Lint-staged

Here are the ideas in order of increasing complexity of implementation and lead time:

1. Fastify
2. Husky + Lint-staged
3. Linting & Formatting for root, server and webdriver-*
4. NVM -> FNM
5. NPM -> PNPM
6. Turborepo / Lerna+NX

[krausest]

I don't want to sound frustrating, but I'm very reluctant making changes 2-6 (i.e. 1 might be a really nice idea).
I'm doing this benchmark for almost seven years and I 'm still excited running new implementations. But sometime the JS fatigue can be a real enemy. We had yarn. It was much cooler than the old npm. At least I thought so until some implementations couldn't be build with yarn that built fine with npm.
So I'm really striving for keeping building as mainstream and simple as can be. It's issues like #1161, #1053, #221 and #182 that cost a lot of energy for no benefit.
The npm rebuild-ci approach allows me to make quite automated and safe updates for the frameworks. I doubt there's a significantly more efficient way for doing so. Rebuilding all implementations is taking a lot of time, but according to my experience there's a big chance that some framework is broken (despite using the same node version, the same package.json and the same package-lock.json.... And things get worse when switching to a new node lts version.) We had a lerna build process (#762) but I found the simpler sequential build far more helpful to fix those issues.

The #1 priority for this project is to have a very robust build processes for each implementation according to the best practices of the framework.

[nakrovati]

Sounds logical, since all the build scripts work. You just wrote that it takes you 12 hours to build and benchmark all packages, so I thought it was too much. I rather want to improve something that won't interfere with the development of a fast package tester.

To implement Turboprepo / Lerna+NX or to change NPM to PNPM is quite difficult and time-consuming with all already working code, but to add FNM (just a few lines of code to change), to implement linter and formatter (even if only for error highlighting in IDE), or to add Husky + Lint-staged is quite easy, at least it seems so to me. Just when I started to study the files it seemed to me that there are a lot of improvements that could be made, that's why I asked here what you as the author of the project would approve.

If I understood you correctly, you are not against Fastify, so I'll do it for now (I'm annoyed by the slowness and lag in Express development).

[krausest]

Building the benchmarks is OK. I'd say it's 45 to 60 minutes. Running the benchmarks takes much longer. It took about 16 hours for chrome 115. During that time my notebook is blocked (i.e. needs good timing).

On OSX I'm no longer using the Dockerfile - maybe I should remove it since it gets no more testing. I'm using a linux VPS to build the frameworks. For single updates I connect via ssh on the remote server, for the complete benchmark I download the ZIP and run the server locally.

Fastify sounds like a nice idea!

[nakrovati]

Ahahahaha, I just fixed the Dockerfile as it kept getting startup errors (mainly NVM & it took all day). No luck for me.

Understood at the expense of Fastify. I will do it the best way I can.

By the way, what version of Node.js are you using to run all of this? I just don't want to accidentally add some new API that will mess things up for you later.