-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
2.0.0 Breaking Changes #501
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
Comments
Potential other changes that need discussions:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I'm sorry to be that type of dev but... Do you have a ETA/roadmap for v2.0.0? We are working to move Quasar TS extension from TSLint to ESLint using this package, but some things you'll resolve in v2 are things we'll need asap. |
@IlCallo - what PRs are you waiting for specifically? Having a quick look at the linked issue..
|
#524 is the main problem we have, because if doesn't allow people working on SFC to access your linting capabilities, forcing to separate the typescript part into a second file. It's not "blocking" in any way, we'll probably migrate to typescript-eslint anyway, but we'd like to have that problem solved by day-0 when we release the update, that's why we were thinking about forking the repo :) I was asking a roadmap/ETA to better coordinate the efforts |
The optimistic plan is to look into handling all of the breaking changes within the next week or two. But as we're all volunteer maintaners, life could get in the way of that.. Note #404 will hard block you guys though. You cannot migrate to |
Ok, I'll take a closer look to #404 and see if I can help to resolve that |
FYI for any subscribers to this issue, we have begun merging breaking change PRs and the canary releases (i.e. We will likely promote v2.x.x to stable in one week. We won't leave such a big gap until v3.x.x but we also want to be mindful of churn, so if you do have breaking changes you want to see now is the time to champion/implement them :) Please also do us a favour and install from Thanks! |
Installed canary been using it for a 2 days and seems fine |
Thanks @corbinu - I have just published a new canary manually: |
This comment has been minimized.
This comment has been minimized.
Unfortunately we haven't quite been able to get everything wrapped up within the week. We will let the updated v2 alphas bed in for one more week and then publish v2 to latest next weekend. Please help us by testing out the latest alphas on your codebases!
|
Thanks @JamesHenry for follow-up. |
I'm not very well at the moment, so we are pushing the release back a few more days. I have just published |
Take care @JamesHenry! |
I wanted somewhere to keep track of the breaking changes we should make as part of a 2.0.0 release.
Deprecated Rules:
prefer-interface
(replaced byconsistent-type-definitions
)no-triple-slash-reference
(replaced bytriple-slash-reference
)consistent-type-assertions
#731) remove deprecated ruleno-angle-bracket-type-assertion
(replaced byconsistent-type-assertions
)consistent-type-assertions
#731) remove deprecated ruleno-object-literal-type-assertion
(replaced byconsistent-type-assertions
)Misc:
isTypescriptFile
checks Make typescript-eslint rules compatible with .vue files #524consistent-type-assertions
#731) generalizeno-angle-bracket-type-assertion
(Rule suggestion: generalize @typescript-eslint/no-angle-bracket-type-assertion #332) and merge inno-object-literal-type-assertion
project
set #760) protection against most common performance pitfallexplicit-function-return-type
allowExpressions
shouldn't ignoreexport default () => {}
renamewill do in v3@typescript-eslint/experimental-utils
to@typescript-eslint/utils
(feat: Move shared types into their own package #425 (review))look into renaming a number of rules Suggestion: standardize against prefixing rule names with "no-" #203will do with a later major bump..Recommended stuff:
explicit-function-return-type
more relaxed by default, as it's the standard usage ([explicit-function-return-type] Consider allowExpressions=true and allowTypedFunctionExpressions=true as default #493)allowAny
option from thepromise-function-async
rule and make it the default (from comment below)The text was updated successfully, but these errors were encountered: