@ts-ignore for the block scope and imports

[zpdDG4gta8XKpMCd]

currently @ts-ignore only mutes the errors from the line immediately below it

would be great to have the same for

1. the whole next block
2. also for all imports

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

[bluelovers]

need this lol

[jeahyoun]

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.

[DrSensor]

one of my use case to use custom bundling a.k.a partial import in mathjs

// 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

[ptallett]

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.

[DanielRosenwasser]

@ptallett you can just compile .js files using allowJs and including it in the compilation. By default, we don't issue errors on .js files unless the file has a // @ts-check comment at the top, or you turn on checkJs.

[ExoMemphiz]

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?

[anodynos]

Using lodash & especially lodash/fp with TypeScript is so painful, and even with latest versions of lodash & @types/lodash you can end up with very cryptic error messages.

If we can have a @ts-ignore-block that ignores errors for the following block, it would be great for use cases like this where you know what you're doing :-)

[jnwu]

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?

[dwilhel1]

Also seeking an update on this request. Thanks!

[code-elf]

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.)
Along with this issue, #19139 would be very important, because especially when applying to large parts of code, you'll only want to disable specific inspections.

[pungggi]

with suppressing the hole file this could be added to Editors like vs code to save in workspace settings or such.

[mszczepanczyk]

Also need this. I'm auto-generating a whole ts file with types for my GraphQL schema using graphql-code-generator and there's an extraneous import triggering noUnusedLocals.

[marianturchyn]

/* tslint:disable */

code

/* tslint:enable */

[Blanen]

// @ts-ignore-start
// @ts-ignore-end

Can be combined with: #19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn this isn't tslint.

[lonix1]

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:

// @ts-ignore-file

[mgol]

@lonix1 You use case is covered by:

// @ts-ignore-start
// @ts-ignore-end

You don't have to use the // @ts-ignore-end part. Many lint tools work that way.

[lonix1]

@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.
Can anyone else get it to work?

[mgol]

@lonix1 I meant that @Blanen's proposal would also work for you, we don't need TypeScript to implement both // @ts-ignore-start + // @ts-ignore-end and // @ts-ignore-file, implementing // @ts-ignore-start + // @ts-ignore-end would be enough. This is not implemented, that's why this issue is still open.

[matthiasg]

@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.

[fgcui1204]

Need this feature.

[haggholm]

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).

[RyanCavanaugh]

@haggholm any reason to prefer ts-ignore over public metadata!: IEncryptedJSONContainer ?

[haggholm]

@RyanCavanaugh Ignorance! I had missed that feature in the documentation. Sorry; please ignore.

[earonesty]

ts(2551) frequently has false positives because of browser-specific features, like mozRTCPeerConnection, etc. but i would like to ignore code blocks. i feel like this is a weirdly normal feature to be missing.

[thetayloredman]

Again. ts-ignore should apply on AST elements like prettier-ignore. Then we don't need this feature because you can easily just /* @ts-ignore */ { ... }

[zm-cttae]

A place where block TS ignore comments would be useful - mixed compilation and wrappers:

https://github.com/metadevpro/ts-pegjs/blob/fb76fa08979af650780cfbc234ffdb67c00ea894/src/passes/generate-ts.ts#L43-L50

---

Just to chime in without spamming - it's much more useful to post your use case than it is to post +1 as a comment of 0 textual import

[PulkitBanta]

Adding this feature will make DX good and code readability will be improved as well. Currently either you have to create another file or disable for the whole file which is not a good solution. Another solution is to disable every line which is way worse for code readability

[DKeken]

i need it :(

[StiliyanHoody]

+1 Bump.

[angrybacon]

Please try to avoid spamming the thread with frequent +1's and use reactions in the initial post. Some of us subscribe to GitHub issues in order to follow progress on features we care about and the noise is not needed

Thanks in advance!

Edit: noise is how people (and maintainers) unsubscribe from your very important issue

[StiliyanHoody]

+1, Agree.

[ZeldOcarina]

Noise is on purpose to remind everyone this is important..

[thw0rted]

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 @ts-ignore. I genuinely appreciate that it takes more time and effort to learn those alternatives. That's especially galling if you didn't even ask to use TS in the first place -- maybe you inherited a TS project, or you're a vanilla JS dev whose userbase is asking for TS support, etc. Please understand that the team is trying to balance ease of use against exactly how big of a foot-gun they should make available.

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.

[ZeldOcarina]

BUMP!!

[thiagomgd]

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 nocheck on some files. On a first look, seems most of the necessity was with things related to Redux, which we should be getting rid of at some point.

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 ts-ignore, or fix things, which is not going to happen. If I could just ignore an entire function or block, I could ignore the mapStateToProps and mapDispatchToProps functions that need it, while keeping the check for the rest of the file, without spamming I-don't-know-how-many ts-ignore there

[emrea-works]

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 😁

#19573 (comment) ↰

ESLint-like statement could be applied as well in order to stay globalized:

/* @ts-ignore-enable */
// risk-taken Javascript code...
/* @ts-ignore-disable */

[LucasJantschChitolina]

need this, +1

[spacecowgoesmoo]

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.

[akarola-IDG]

why still not added?

[dwilhel1]

why still not added?

Today is the Thanksgiving holiday in the USA where Microsoft is headquartered 🦃

[yolpsoftware]

why still not added?

Today is the Thanksgiving holiday in the USA where Microsoft is headquartered 🦃

Right. They can do it tomorrow then.

[HolgerJeromin]

why still not added?

Probably because it would be no good feature in most cases:
#19573 (comment)

[AltairTF]

Why not close this and admit it will never be added?

[RyanCavanaugh]

Why not close this and admit it will never be added?

People don't like it when we do that either!

[thetayloredman]

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.

[thetayloredman]

..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: ***@***.***>

[WhyINeedToFillUsername]

I can't see the Ryan's comment here (only in email), I am replying to this:

// @ts-ignore the constraint violation error is wrong
function foo(a: IsViolatingConstraint<T>) {
  return a.widht; // <-- oops, no typechecking now
}

• is there a problem to limit the ignore to specific issue only? I agree that blanket ts-ignore is not desired, but ignoring a specific issue would be very helpful.

[HolgerJeromin]

is there a problem to limit the ignore to specific issue only? I agree that blanket ts-ignore is not desired, but ignoring a specific issue would be very helpful.

Which would be #19139

[nurbek-mirai]

Bump.

[DeepDoge]

This would be really useful for JS with JSDoc, since in JSDoc we can't do things like as never, to force a type, when we know better than the typing system.

[weswigham]

This would be really useful for JS with JSDoc, since in JSDoc we can't do things like as never, to force a type, when we know better than the typing system.

func(/** @type {*} */(expression_with_wrong_type));