Skip to content
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.

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

upgrade parser & plugin to 2.19.0 #224

Merged
merged 4 commits into from
Feb 11, 2020
Merged

upgrade parser & plugin to 2.19.0 #224

merged 4 commits into from
Feb 11, 2020

Conversation

mightyiam
Copy link
Owner

No description provided.

@request-info
Copy link

request-info bot commented Feb 4, 2020

👋 We would appreciate it if you could provide us with more information about this issue.

@mightyiam mightyiam changed the title upgrade parser & plugin to 2.19.9 upgrade parser & plugin to 2.19.0 Feb 4, 2020
@@ -46,8 +48,10 @@ test('export', (t): void => {
'space-before-function-paren': 'off',
'@typescript-eslint/adjacent-overload-signatures': 'error',
'@typescript-eslint/array-type': ['error', { default: 'array-simple' }],
'@typescript-eslint/ban-ts-comment': 'error',
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, this will be a breaking change for us 😬

It would also be a bit weird to disable the warning on a per-case basis since it would then always be two "magical" comments:

/* eslint-disable-next-line */
// @ts-ignore
foobar()

In my opinion, if someone has already made the special comment @ts-ignore, they know what they are doing. I'm not sure that the linter should enforce that we never use it.

I find that there are still quite a few legit cases where it has to be used simply because TypeScript can't express everything that JS does at the moment...


sidenote: I'm also not sure about disallowing ! as we do now. Sometimes it's simply needed because TypeScript haven't understood that we have already checked the condition in some way...

Copy link
Owner Author

Choose a reason for hiding this comment

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

@LinusU is there a @ts-ignore where any would not be a better alternative?

Regarding no-non-null-assertion, could you please make that an issue, if you find it a burden?

Copy link
Owner Author

Choose a reason for hiding this comment

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

@LinusU removed it from this pull request.

Copy link
Contributor

Choose a reason for hiding this comment

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

I actually think that @ts-ignore is a much cleaner way to signal something that isn't possible with TypeScript at the moment than just casting to any.

  • Since any already has a legitimate use case it's hard to search your entire codebase for it, and it doesn't stand out as much when you see it.
  • @ts-ignore lets you very easy add context on why you have to ignore it. Most of the time I will link to a TypeScript issue directly in the comment:
    // @ts-ignore https://github.com/microsoft/TypeScript/issues/26113

Thanks for removing it ❤️ I'm open to discussing this further if you want to 👍

@@ -86,6 +90,7 @@ test('export', (t): void => {
}
],
'@typescript-eslint/no-array-constructor': 'error',
'@typescript-eslint/no-dupe-class-members': 'error',
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice! 👍

@@ -102,10 +107,12 @@ test('export', (t): void => {
'@typescript-eslint/no-misused-new': 'error',
'@typescript-eslint/no-misused-promises': 'error',
'@typescript-eslint/no-namespace': 'error',
'@typescript-eslint/no-non-null-asserted-optional-chain': 'error',
Copy link
Contributor

Choose a reason for hiding this comment

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

This won't do anything at the moment since @typescript-eslint/no-non-null-assertion makes it so that you can never come here. But it's still nice to enable it, since we might change @typescript-eslint/no-non-null-assertion in the future 👍

'@typescript-eslint/no-non-null-assertion': 'error',
'@typescript-eslint/no-this-alias': ['error', { allowDestructuring: true }],
'@typescript-eslint/no-throw-literal': 'error',
'@typescript-eslint/no-unnecessary-type-assertion': 'error',
'@typescript-eslint/no-unnecessary-boolean-literal-compare': 'error',
Copy link
Contributor

Choose a reason for hiding this comment

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

Neat 👍

BREAKING CHANGE: new rule @typescript-eslint/no-non-null-asserted-optional-chain
typescript-eslint/typescript-eslint#1469

BREAKING CHANGE: [no-extra-non-null-assertion] flag optional chain after a non-null assertion
typescript-eslint/typescript-eslint#1460

Closes #218.
BREAKING CHANGE: new rule @typescript-eslint/prefer-as-const
typescript-eslint/typescript-eslint#1431

Closes #218.
BREAKING CHANGE: new rule @typescript-eslint/no-unnecessary-boolean-literal-compare
typescript-eslint/typescript-eslint#242

BREAKING CHANGE: new rule @typescript-eslint/no-dupe-class-members
https://github.com/typescript-eslint/typescript-eslint/blob/v2.19.0/packages/eslint-plugin/docs/rules/no-dupe-class-members.md

BREAKING CHANGE: new rule @typescript-eslint/switch-exhaustiveness-check
https://github.com/typescript-eslint/typescript-eslint/blob/v2.19.0/packages/eslint-plugin/docs/rules/switch-exhaustiveness-check.md

Closes #223.
BREAKING CHANGE: upgrade plugin peerDep
@mightyiam mightyiam merged commit 612b9ba into master Feb 11, 2020
@mightyiam mightyiam deleted the 2.19.0 branch February 11, 2020 12:27
@mightyiam
Copy link
Owner Author

Thank you for the review, @LinusU .

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

Successfully merging this pull request may close these issues.

2 participants