Skip to content

Use local prettier instance for parsers#706

Merged
CiGit merged 1 commit intoprettier:masterfrom
JHilker:use-local-prettier-instance-for-parsers
Jan 31, 2019
Merged

Use local prettier instance for parsers#706
CiGit merged 1 commit intoprettier:masterfrom
JHilker:use-local-prettier-instance-for-parsers

Conversation

@JHilker
Copy link
Copy Markdown
Contributor

@JHilker JHilker commented Jan 31, 2019

Resolves #705

As part of 1.16.0 of Prettier, the parsers for each version were swapped from babylon to babel. However this causes the default parser to be used for any local version of Prettier to be babel, even if babel isn't a valid parser for that version.

This switches the dynamicParser interpretation to use the local version of Prettier, which will properly include babylon instead of babel, allowing the extension to run properly on local Prettier instances < 1.16.0 and avoid throwing Couldn't resolve parser "babel"

First time contributor, so please let me know if an alternative approach would be preferred, just hoping to get this fixed ASAP. (and avoid migrating a few hundred repos this week 😬).

Copy link
Copy Markdown
Member

@CiGit CiGit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is the right fix for this exact problem. IMO the fix lays inside getSupportInfo (on prettier's side)

BUT

I like it.
This is a first step toward plugin support :-)

and it fixes a current problem

function getSupportLanguages(version?: string) {
return (require('prettier') as Prettier).getSupportInfo(version).languages;
function getSupportLanguages(prettierInstance: Prettier = bundledPrettier) {
return prettierInstance.getSupportInfo(prettierInstance.version).languages;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't remember when prettier.getSupportInfo was added to prettier. But on quite old prettier versions, this may break.

Copy link
Copy Markdown
Contributor Author

@JHilker JHilker Jan 31, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like getSupportInfo was added in prettier/prettier#3033 which only landed in 1.8.0. Think it's worth adding a fallback to bundledPrettier.getSupportInfo if getSupportInfo isn't defined?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in #707

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It still would resolve to "babel" instead of "babylon". Without a fix in getSupportInfo. So quite pointless right now.

1.8 is 1 year old. Let's expect no one is using it with this extension 😆
Monitoring issues ...

Solution could be to simply use bundled if local version is below a given version. vscode now allows us to easily downgrade an extension. I think we would need to do that to support plugins anyway without having to support too many code path and keep this extension simple.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without a fix in getSupportInfo. So quite pointless right now.

Yeah, it'll only be useful once there is an upstream fix in getSupportInfo, but required if that does happen. 🤷‍♂️

1.8 is 1 year old. Let's expect no one is using it with this extension 😆

You have more faith than I do in people updating deps! 😂 But if you don't think it'll be an issue, works for me 👍

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have more faith than I do in people updating deps! joy But if you don't think it'll be an issue, works for me +1

Prettier was new and it's not a major version change. That's why I'm expecting so. and certainly mistaken. Let's push people to upgrade their deps 😃

@CiGit
Copy link
Copy Markdown
Member

CiGit commented Jan 31, 2019

Thank you for your contribution!

@CiGit CiGit merged commit 05f7eea into prettier:master Jan 31, 2019
@briandk
Copy link
Copy Markdown
Contributor

briandk commented Jan 31, 2019

@JHilker @CiGit Should this update be noted in the changelog for the future release?

@JHilker
Copy link
Copy Markdown
Contributor Author

JHilker commented Jan 31, 2019

IMO the fix lays inside getSupportInfo (on prettier's side)

Yeah, I think you are right here. But it seemed like a reasonable forward thinking workaround 😂. Hopefully getSupportInfo can get fixed as well.

@JHilker JHilker deleted the use-local-prettier-instance-for-parsers branch January 31, 2019 21:52
@CiGit
Copy link
Copy Markdown
Member

CiGit commented Jan 31, 2019

@briandk Too late. Already released. But it would have been a good idea. We should have a PR template!

With a quick glance at getSupportInfo, it would need some changes... It only supports filtering languages not parsers.

@JHilker
Copy link
Copy Markdown
Contributor Author

JHilker commented Jan 31, 2019

Too late. Already released.

Looks like the version in the repo hasn't been updated to 1.8.1. Should it get the bump?

@CiGit
Copy link
Copy Markdown
Member

CiGit commented Jan 31, 2019

Looks like I forgot to push ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1.8.0 problem

3 participants