Skip to content

api: remove the version parameter of getSupportInfo #7620

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
thorn0 merged 7 commits into from
Feb 23, 2020
Merged

api: remove the version parameter of getSupportInfo #7620

thorn0 merged 7 commits into from
Feb 23, 2020

Conversation

@thorn0
Copy link
Member

@thorn0 thorn0 commented Feb 18, 2020 •
edited
Loading

closes #7615

  • I’ve added tests to confirm my change works.
  • (If changing the API or CLI) I’ve documented the changes I’ve made (in the docs/ directory)
  • (If the change is user-facing) I’ve added my changes to changelog_unreleased/*/pr-XXXX.md file following changelog_unreleased/TEMPLATE.md.
  • I’ve read the contributing guidelines.

✨Try the playground for this PR✨

fisker
fisker reviewed Feb 18, 2020
View reviewed changes
@fisker
Copy link
Member

fisker commented Feb 18, 2020

We may want switch those support infos to JSON scheme some day.

@thorn0
Copy link
Member Author

thorn0 commented Feb 18, 2020

@fisker Would we need that version parameter for that?

@fisker
Copy link
Member

fisker commented Feb 18, 2020

I agree that we don't need it. I mean after removing this, support info is just some property validate info, we can use ajv to validate.

fisker
fisker reviewed Feb 18, 2020
View reviewed changes
src/main/support.js Outdated
// we need to treat it as the normal one so as to test new features.
version = currentVersion.split("-", 1)[0];
function getSupportInfo(
_,
Copy link
Member

@fisker fisker Feb 18, 2020

Choose a reason for hiding this comment

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

Can we remove this parameter, and wrap in the export?

Copy link
Member Author

@thorn0 thorn0 Feb 18, 2020

Choose a reason for hiding this comment

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

That would break type inference and overall I think the code is cleaner (less confusing) the way it is now.

Copy link
Member Author

@thorn0 thorn0 Feb 18, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

Nevertheless, I did something with this. (I don't like it though. Adding types to that will be difficult.)

@thorn0 thorn0 marked this pull request as ready for review February 19, 2020 09:51
sosukesuzuki
sosukesuzuki approved these changes Feb 19, 2020
View reviewed changes
Copy link
Contributor

@sosukesuzuki sosukesuzuki left a comment

Choose a reason for hiding this comment

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

Good job! We should fix the type definition after release.

@thorn0
Copy link
Member Author

thorn0 commented Feb 23, 2020

Merging this to move forward with other changes.

@thorn0 thorn0 merged commit cf3d9f0 into prettier:next Feb 23, 2020
@lydell lydell mentioned this pull request Feb 23, 2020
Closed
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@fisker fisker fisker left review comments

@sosukesuzuki sosukesuzuki sosukesuzuki approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@thorn0 @fisker @sosukesuzuki