🐛 BUG: 0.1.0-next.3 is much slower than 0.0.12 - hangs vscode temporarily

[hayley]

Describe the Bug

To be specific, in the examples below next is 0.1.0-next.3 and latest is 0.0.12.

I'm currently converting a project from Astro 0.20 to Astro 0.25 and also upgrading prettier at the same time to the next version, and I'm running into an issue where formatting on save in VSCode noticeably hangs the editor for several seconds.

On my project:

npm install -D prettier-plugin-astro@latest
npm run format
[...]
Done in 1.44s.

npm install -D prettier-plugin-astro@next
npm run format
[...]
Done in 13.61s.

If I run the yarn prettier -w . several times in a row with the next version, they'll all be around 13 seconds, even though the subsequent runs wouldn't require writing any new changes.

Steps to Reproduce

I tried reproducing this with entire folders from the example projects but unfortunately latest would often fail on files so it wasn't easy to show a complete comparison but for the projects below running yarn prettier -w . was noticeably slower on next :

• blog
• blog multiple authors
• ssr
• docs

For a VSCode demonstration:

npm init astro -- --template blog-multiple-authors
npm install -D prettier-plugin-astro@next
code .
open src/pages/posts/[...page].astro
make no changes and save

This will result in VSCode hanging for about 6-7 seconds every time I save.

Let me know if you need any details about my VSCode setup (though this is happening at the command line too of course).

[antonyfaris]

Hi, thanks for opening this issue. We are aware of this problem. This happens due to the package make-synchronous that we use while we wait for Prettier to support esm. next is a pre-release meant for testing. I suggest you keep using latest for production.

[hayley]

Thanks for the quick reply!

I had run into a transient error earlier in the upgrade using latest on the project so I thought maybe that next was the way to go for 0.25, but since that seems resolved (may have been a temporary syntax error I introduced when upgrading), I'll keep using latest for now.

Thanks again!

[jasikpark]

Hi, thanks for opening this issue. We are aware of this problem. This happens due to the package make-synchronous that we use while we wait for Prettier to support esm. next is a pre-release meant for testing. I suggest you keep using latest for production.

Is that b/c @astrojs/compiler doesn't support cjs?

[jasikpark]

Thankfully it looks like prettier is working on transitioning to support esm: prettier/prettier#10157 (comment)

[jasikpark]

https://github.com/prettier/prettier/pull/12343/files might be a good case study in how to write it 🤔

[jasikpark]

Also tracked by prettier/prettier#4459 which would make the parser async?

[jasikpark]

https://github.com/rx-ts/synckit suggested in prettier#4459 might be a faster solution in the meantime than make-synchronous: prettier/prettier#4459 (comment)

[antonyfaris]

Is that b/c @astrojs/compiler doesn't support cjs?

Yes, that's correct.

Thankfully it looks like prettier is working on transitioning to support esm: prettier/prettier#10157 (comment)

Also tracked by prettier/prettier#4459 which would make the parser async?

Yeah, we are keeping an eye on those issues.

https://github.com/prettier/prettier/pull/12343/files might be a good case study in how to write it 🤔

https://github.com/rx-ts/synckit suggested in prettier#4459 might be a faster solution in the meantime than make-synchronous: prettier/prettier#4459 (comment)

Thank you for the suggestions!

[jasikpark]

I'm glad to see that synckit seems to dramatically improve things! v0.1.0-next.4 runs about the same speed as 0.0.11 for me 😁

[Princesseuh]

Closing at this has been fixed in v0.1.0-next.4. Performance is still not perfect, however it's much much better than before