fix: use synckit to support Prettier 3

[idahogurl]

What

Closes #171

Breaking Changes

• prettier-eslint must be installed locally by the user
• Prettier v3.0 is now required
• ESLint >= v8.52.0 is now required

Why

Prettier 3 added a dynamic import() in its .cjs file, making ESM support required. VS Code only supports CommonJS (CJS) however. According to this comment prettier/prettier-vscode#2947 (comment), VSCode extensions can use worker_threads and a Worker can execute import().

Thus, this PR makes it so that instances of prettier-eslint are run on Worker of worker_threads.

[JounQin]

@idahogurl AFAIK, you can use await import() directly in cjs, can't you? For legacy TypeScript, you can use this hack:

https://github.com/just-jeb/angular-builders/blob/e8d063cd16346514d55ec6e25d41c184a999ca42/packages/custom-webpack/src/utils.ts#L68-L70

[idahogurl]

@idahogurl AFAIK, you can use await import() directly in cjs, can't you? For legacy TypeScript, you can use this hack:

https://github.com/just-jeb/angular-builders/blob/e8d063cd16346514d55ec6e25d41c184a999ca42/packages/custom-webpack/src/utils.ts#L68-L70

@JounQin That would work if I was bundling prettier since esbuild would convert the ESM to CJS but it is an external dependency.

[JounQin]

That doesn't matter with external and no need to bundle at all for regular commonjs, but I'm not so familiar with VSCode/vmscripts.

Regularly, await import('esm.mjs') is just supported, so await import('prettier') should just work.

If it doesn't work, then synckit should be a good choice.

[JounQin]

If you need any help, I can help to raise a new PR based on this one later for you.

[JounQin]

Can you update the PR title accordingly?

[netux]

I did some quick debugging and found out there is still a bottleneck with the worker having to load prettier-eslint, which on my machine takes roughly 2-3 seconds.

Also the preload did nothing for me because, from a VSCode window reload with a document already opened, the extension is only activated when the formatter is run.

I think a solution would be to:

1. Add onStartupFinished to the "activationEvents" field in the package.json, to make sure the extension is ready after VSCode starts.
2. On load, run formatText() with some dummy document to force the engine to go through the code paths that a real document would go through, and load all the necessary things that way.

[JounQin]

@netux I think you can just raise a PR for your proposal.

[netux]

@netux I think you can just raise a PR for your proposal.

Good idea! I have opened #202 🙂.

[JounQin]

I believe supportedLanguages should not be hard coded because of 3rd-party plugins. But it can be done in next minor version, I'd like to PR after v3 released later.

[JounQin]

I think we are just ready to go! Congratulations!

[novarolV]

I have opened #206 to address an issue on Windows.