-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
@ts-ignore for the block scope and imports #19573
Comments
need this lol |
Current use case for this feature is a unit test that deals with whitespace. We have the "no-trailing-whitespace" rule turned on in our codebase for good reason, but not being able to overpower it on a block level means that we can't easily test for trailing whitespace and carriage returns using an ES6 template string. |
one of my use case to use custom bundling // tslint:disable:no-var-requires
import core from 'mathjs/core'
// @ts-ignore
import mathUnit from 'mathjs/lib/type/unit'
// @ts-ignore
import mathExpression from 'mathjs/lib/expression/function'
// @ts-ignore
import mathArithmatic from 'mathjs/lib/function/arithmetic'
const math = core.create()
// math.import(require('mathjs/lib/type/unit'))
// math.import(require('mathjs/lib/expression/function')) // compile, eval
// math.import(require('mathjs/lib/function/arithmetic')) // basic arithmetic like divide, exponent, etc
math.import(mathUnit)
math.import(mathExpression) // compile, eval
math.import(mathArithmatic) // basic arithmetic like divide, exponent, etc
export const unit = math.unit
export const createUnit = math.createUnit
export const compile = math.compile |
I'd like to ignore errors for a whole file. I have inherited some ES6 JS code I'd like to transpile to ES5 but have to use Babel at the moment. Would be nice to just rename the file to .ts and transpile with TS. |
@ptallett you can just compile |
I would still love this functionality, I am sitting in a test file, it has the extension .ts, so I can import and easily see what parameters go where, and compiling it to a directory beside the src files is brilliant for my use case. Most of my lines are now red, as I purposefully try to exclude some parameters, or give a different type to the function, than it originally takes, and expect an error thrown, as I check for it in runtime as well. It would be lovely to not have a bunch of red lines everywhere. :) Is there any update on it, or has anyone found some good way of doing this? |
Using If we can have a |
I am working with legacy code with numerous global scoped variables, and writing @ts-ignore on every line is become tedious, any updates on this? |
Also seeking an update on this request. Thanks! |
This would also be very important for what I'm doing (namely type-checking generated Vue template render functions, which would require disabling specific inspections for a block of code.) |
with suppressing the hole file this could be added to Editors like vs code to save in workspace settings or such. |
Also need this. I'm auto-generating a whole ts file with types for my GraphQL schema using |
/* tslint:disable */ code /* tslint:enable */ |
Can be combined with: #19139
@marianturchyn this isn't tslint. |
Sometimes while I'm moving stuff around and refactoring, I want to temporarily ignore the whole file (i.e. not compile it), without fiddling with the CLI options. The quickest/easiest is a flag at the top of the file:
|
@lonix1 You use case is covered by:
You don't have to use the |
@mgol I don't want to derail this thread... but I tried your suggestion - thanks! - and it didn't work for me. I put the lines together at the top of the file, and also tried one at the top and the other at the bottom. |
@lonix1 I meant that @Blanen's proposal would also work for you, we don't need TypeScript to implement both |
@DanielRosenwasser this would only work when the ts files get stored in another folder during build. when the project is setup to place js files next to the ts files it wont. Also will js files be 'compiled' e.g. transform to es5 ? When transporting legacy code this would really be helpful. |
Need this feature. |
Use case: TypeORM expects us to create DB entity classes that have columns that may or may not be nullable. Many columns (hence) are not nullable…and hence should be treated, except in the class definition, as if the properties are unconditionally of certain defined types. However, Typescript requires us to define every column as being strongly typed. Hence, we end up with a great many entities like: @Entity('investigation')
export class InvestigationEntity {
@PrimaryGeneratedColumn('uuid')
// @ts-ignore TS2564
public investigationId: string;
@Column({ type: 'uuid' })
// @ts-ignore TS2564
public userId: string;
@Column({ type: 'jsonb' })
// @ts-ignore TS2564
public metadata: IEncryptedJSONContainer;
} Every column is required and (hence) certain to contain a value, but due to the way TypeORM works, every property must be defined in such a way that it lacks an initializer. It would be extremely convenient to be able to suppress this particular, ORM-derived/specific issue, for an entire class (hence/or file). |
@haggholm any reason to prefer |
@RyanCavanaugh Ignorance! I had missed that feature in the documentation. Sorry; please ignore. |
Noise is on purpose to remind everyone this is important.. |
At the risk of just re-hashing my previous comments yet again: I think this issue is attracting a lot of attention from people who are frustrated with the language. They just want to make their errors go away, and they want an equivalent to the directives they already use to turn the linter off so it stops making all those angry squiggles in the editor. TS provides a number of other ways to address your problems, introducing varying degrees of unsoundness. I say this with all the understanding in the world, I really do, but 9 out of 10 people watching this issue could solve their problems more effectively without With that said: it really isn't helping your case to send an email to 1000+ people saying how much you really want this feature. If it's important to you, take a little time to read some of the backchat, then explain why the previous suggestions don't meet your needs. |
BUMP!! |
On my current project that I joined more recently, having this would help a lot for a bit. Context: at some point, they had to migrate to React 16. There were a bunch of TS errors in some files, so they added Of course, with shifting priorities and all, they never got to remove those. Now, I'm on a deadline to migrate to React 18, and will either have to migrate without TS check for those files, change from nocheck to individual |
This comment was marked as off-topic.
This comment was marked as off-topic.
By the way in order of secure code compilation, maybe extending of rule-disabling must be avoid at the development of Typescript. So, developer gets pushed to reduce and properly implement their non-ruled codes, I agree that. Otherwise 😁 ESLint-like statement could be applied as well in order to stay globalized:
|
need this, +1 |
I solved my issue with a refactor but it still seems bad to not have this as an option. There's 6 years of other people with use cases posted in here at this point. |
why still not added? |
Today is the Thanksgiving holiday in the USA where Microsoft is headquartered 🦃 |
Right. They can do it tomorrow then. |
Probably because it would be no good feature in most cases: |
Why not close this and admit it will never be added? |
|
Again.. just apply ts-ignore to the following AST element. Almost every other ignore works that way (e.g. Prettier) and this solves the issue. I'm shocked TS doesn't do this. |
..Good point, I didn't think of that.
…On Wed, Jan 3, 2024 at 4:28 PM Ryan Cavanaugh ***@***.***> wrote:
Again.. just apply ts-ignore to the following AST element.
That's absolutely not what people want, since it implies that if you had
something like
// @ts-ignore the constraint violation error is wrongfunction foo(a: IsViolatingConstraint<T>) {
return a.widht; // <-- oops, no typechecking now}
—
Reply to this email directly, view it on GitHub
<#19573 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGJBKAILYJHN2XXH2JC6RN3YMXZUHAVCNFSM4EBNELN2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBXGYYTIOJWGEYQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I can't see the Ryan's comment here (only in email), I am replying to this:
|
Which would be #19139 |
Bump. |
This would be really useful for JS with JSDoc, since in JSDoc we can't do things like |
func(/** @type {*} */(expression_with_wrong_type)); |
wait did this ever get implemented? #19573 (comment) (I assume not but I choose to have hope) |
+1 |
refactoring js -> ts, would love to have this feature so I could partially refactor a file while ignoring the ts errors in the rest so as to not overwhelm reviewers with an 800 line change summary. Its all tested and working, so I don't need TS to tell me anything about the unconverted js remaining in the file. I just want to break up a refactor and have each step pass CI checks. |
Bruh please. |
Pretty sure all the relevant people have unsubscribed by now with the constant and unnecessary noise so I suppose I'll do that as well
@pm0u Not really what you asked for but have you considered JSDoc as a first step? And if when approaching 100% coverage you still want actual TypeScript, codemod(s) to migrate the syntax |
@angrybacon interesting, I did not know about these (looking at |
+1 |
currently @ts-ignore only mutes the errors from the line immediately below it
would be great to have the same for
use case:
refactoring: commenting out a piece of code to see what would break without it, yet avoiding to deal with the errors in the file where commented code is which can be many
The text was updated successfully, but these errors were encountered: