idahogurl / vs-code-prettier-eslint

A Visual Studio Code Extension to format JavaScript and TypeScript code using the prettier-eslint package.
MIT License
184 stars 46 forks source link

v6.0.0 BREAKING CHANGES #213

Closed iliareshetov closed 4 months ago

iliareshetov commented 5 months ago

Hi, Just wanted to drop a quick question about the recent updates – noticed my go-to extension isn't kicking in anymore (along with probably another 2 million users). No rush, but any chance you could shed some light on the reasons behind such changes ?

Had to do a little morning tech detective work instead of jumping into work right away. Thanks a bunch!

idahogurl commented 5 months ago

@iliareshetov I was afraid of that. The issue was making the extension compatible with Prettier 3. Prettier 3 added a dynamic import() in its .cjs file, making ESM support required. VS Code only supports CommonJS (CJS) however. VSCode extensions can use worker_threads and a Worker can execute import().

When I implemented the worker_threads, I tried bundling prettier-eslint with the worker.mjs but couldn't get it to work. I also couldn't get it to work with an older ESLint version.

I'm thinking there are two options.

  1. Revert my changes and make the Prettier 3.0 version be the a pre-release version. Eventually though the pre-release version will need to be made the official version.
  2. Put the breaking changes notification (making the title caps and adding emojis) at the very top of the extension and README pages.

What are your thoughts?

moselhy commented 5 months ago

Worth noting that even with Prettier 3, 6.0.0 broke support for Yarn PnP using nodeLinker: pnp. I'm getting Error: Cannot find module 'prettier-eslint' on a fresh TS project with all the setup and troubleshooting instructions on the repo's README.

idahogurl commented 5 months ago

@moselhy You can go back to 5.1.0 if you need. You just need to go to the Extension page in VS Code and click the arrow next to Uninstall. Select Install another version and chose 5.1.0.

iliareshetov commented 5 months ago

@idahogurl Thank you for the prompt response and detailed explanation. 👍

I lean towards option 2 as it provides users with upfront information, helping them make informed decisions about their workflow.

Personally, I had to roll back to version 5.1.0 as the only practical solution for the time being, and I'm sure I'm not alone.

monkpit commented 4 months ago

The problem is that our entire team uses this plugin and our workflow was broken by VSCode auto-updating to the latest version.

I think a prerelease version (option 1) makes sense until it can be made to work with older versions and anyone can auto-update without worry. Maybe some config option to select which way the code will work, prettier 2 or 3. Or, have the extension detect which version is in the project on startup.

Another option might be to create another extension and publish it as "For prettier 2" or something. Copy everything from the latest 5.x release and just keep that plugin out there as the old version, and keep your main one (with all the users) on the latest.