Refactoring Build and Development Chain

Refactoring The Build and Development Chain

Currently the project uses rollup for build and jest for testing. EsLint and Prettier is also installed but not properly configured.

My Suggestion is to replace rollup with esbuild and jest with vitest and properly setup EsLint and Prettier to enforce same code style for everyone.

Reasons to consider esbuild over rollup

• esbuild is faster and more efficient than rollup
• It can do everything that rollup is currently doing, without any extra dependency or plugin

Reasons to consider vitest over jest

• vitest provides same API as jest, so nothing needs to be changed in test file
• supports import/export syntax out of box
• directly tests over source code, which skips painful build step before every test run
• tests can be run in watch mode, saving much time

[francisrstokes]

Hey @YetAnotherDeveloperYT,

Thanks for opening the issue! I'll start with the obvious point that is: right now it works, and as the old adage goes: "If it ain't broke, don't fix it" 😄I have limited time to work on arcsecond these days, and when I do, I'm mostly concerned with improving the user facing side of the library. But that said, I'm not against addressing it if you're willing to pick it up and make it work.

esbuild

I've used esbuild in the past and was very happy with the experience and performance. It would also be nice to eliminate an extra dependency, step in the process, and additional config file. Please note that as it currently works, the build process produces both an ES2020 file (.mjs with modules), and an ES6 file (.js with commonjs). This is something that should also happen with any change in build process.

vitest

I haven't used this, but it sounds like a great improvement. If it can test the ts files directly, all the better. I am curious about how it internally compiles the files during testing; If the build process were to move to esbuild, when vitest builds the ts files, would it make use of the esbuild configuration? I don't expect anything strange to happen if it were to use tsc vs esbuild, but thinking of possible edge cases is always a good idea.

directly tests over source code, which skips painful build step before every test run
tests can be run in watch mode, saving much time

While I appreciate the point, I don't think these are really strong considerations. The project builds in something like 2.5seconds on my machine, and the tests run in less than a second. To me, 3 seconds is not what I'd call painful (I have C projects at work that can take 3 minutes to compile for a clean build - and that is painful!). Still, I'd be happy to accept the changes if they improve the library.

If you do choose to pick these up, please open two separate PRs; one for esbuild, and one for vitest.