-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Throw errors for non-class decorators #185
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
we are reporting error for decorators:
you should enable |
We need to be careful recommending that to Prettier at this stage @armano2 - there’s a major difference in performance to think about right now. |
We should measure for the Prettier case specifically, there’s a big user base to consider |
I'm working on this now |
I've worked on this a bit and we already have precedent for adding decorators on nodes which don't allow them, so I am thinking we should just do that here too to solve them problem for now. Enabling the diagnostics is expensive, it looks like it's around 30% slower for real world usage of Prettier, because it otherwise doesn't need a lot of the Program architecture. That might be fine in many cases, might not in others, hard to tell. But given this specific issue, and the fact we already have precedent for this, I think handling it specifically is probably the best way to go. |
In the future, it would be really nice if there were a way to cheaply report diagnostics on a single |
PR is here: #211 |
RE: the diagnostics on a single sourcefile, they're technically there, but not exposed in the API. I'll ask around tomorrow to see if that's a safe thing to use/depend on or not |
What code were you trying to parse?
What did you expect to happen?
Throw an error.
What actually happened?
No
decorators
attached nor errors were thrown.Versions
@typescript-eslint/typescript-estree
1.1.0
TypeScript
3.2.2
node
X.Y.Z
npm
X.Y.Z
Original post: prettier/prettier#5823
The text was updated successfully, but these errors were encountered: