Modernize workflow

[SunsetTechuila]

The plan:

1. [x] Remove git hooks
2. [ ] Update eslint to v9, overhaul its config
3. [ ] Use semantic-release and github actions to fully automate publishing
4. [ ] Cache everything that can be cached: deps, building, linting and formatting results, vscode releases for tests, etc (partially requires turborepo)
5. [ ] Rewrite tests to make them more flexible
6. [ ] See if it possible to migrate to Bun and use its bundler
7. [ ] If both yes - migrate; if the second is no - consider staying on Node.js and using pnpm
   • [ ] if decided to stay on Node.js - migrate from tsc to esbuild for building
8. [ ] Bundle the extension into a single file

Completing this would allow to resolve #327 and #306

[SunsetTechuila]

@xuhdev thoughts?

[xuhdev]

I agree with what you propose.

For point 1, I would say we only do pnpm not bun at least for now, because bun is still known to have some minor incompatibilities with Node.js and its support is still behind Node.js. Additionally, requiring contributors to install bun is likely a discouraging factor (while it's easy, many people don't want to install an additional piece of software). For these reasons, I don't think the benefit of bun outweighs its disadvantages for our purposes (the dev part is not performance critical).

What do you think?

[xuhdev]

Should we maybe also pin dependencies for better predictability and reliability? See https://docs.renovatebot.com/dependency-pinning/#so-whats-best

[SunsetTechuila]

I don't think it is necessary, since we use a lockfile and tests in ci will fail if it is outdated

[SunsetTechuila]

bun is still known to have some minor incompatibilities with Node.js and its support is still behind Node.js.

Initially, I proposed it as a package manager only, but now I'm going to see if it's possible to replace Node.js entirely with Bun. The built-in test-runner (can be used for unit tests like api.test.ts) and dependency-patching functionality (see https://github.com/editorconfig/editorconfig-vscode/pull/375#issuecomment-2510077731) would be very useful for this project

[xuhdev]

I don't mind, as long as you think its benefit outweighs its cost.

[SunsetTechuila]

I was sceptical about Bun too, but trust me - once you've tried it, you'll never want to go back to Node

[xuhdev]

I don't doubt about the technical excellence of Bun, I like a lot of their features -- I think its negative sides are mostly non-technical and coming from historical burdens in the industry and the current adoption rate. I don't have a strong opinion in advocating for or against Bun, and I haven't used it in a serious project other than having played with it casually.

Since you are a maintainer, I defer to your decision since you definitely have used and understand Bun more than I do 😃

[SunsetTechuila]

Update about moving from tsc for transpiling and bundling: it is not possible to sanely configure tsup to bundle all dependencies expect vscode. The config I ended up with looks like that:

external: ['vscode'],
noExternal: [/^(?!vscode$).+$/],

Atrocious. Not providing a straightforward way to bundle all dependencies is a matter of principle for the developers: 1, 2

Using esbuild directly is anything, but convenient, I have tried that several times and the experience has always been miserable to one degree or another.

But I looked at the docs for Bun's built-in bundler and it seems to be exactly what I'm looking for! Although I'd never used it before as it lacked the features I needed.

As I said:

once you've tried it, you'll never want to go back to Node

[SunsetTechuila]

Bun's built-in bundler and it seems to be exactly what I'm looking for

no, it cannot be used rn https://github.com/oven-sh/bun/issues/5866

[SunsetTechuila]

it's not possible to migrate from tsc for building without rewriting tests first

[SunsetTechuila]

The proposal has been transformed into the plan