Typescript: @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!

[MayaWolf]

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: https://github.com/Microsoft/TypeScript/issues/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.

[quantuminformation]

I would like to do

// @ts-ignore-start
--strick null checks, for one particular file

[trivigy]

This is what unittesting private fields and methods with typescript looks. I have 6 lines dedicated to ignoring code. Awful. Makes my eyes bleed. Any workarounds for block ignoring would be much appreciated.

it('TestNode_ReconnectionsWorkload', async function () {
    for (let i = 0; i < 1; i++) {
        nodes.push(await Node.NewNode(serverUrl, {
            handlers: {
                active: async function (n: Node) {
                    try {
                        // @ts-ignore
                        if (n.view.Empty()) {
                            // @ts-ignore
                            if (n.conns.Empty() && !n.server) {
                                // @ts-ignore
                                await n.login(n.address);
                            }
                            return;
                        }

                        const data = new flats.Message({
                            // @ts-ignore
                            id: n.id,
                            type: flats.MessageType.Data,
                            data: 'hello world',
                        });

                        const dataBytes = data.toBytes();
                        const dataBase64 = base64.encode(dataBytes);
                        // @ts-ignore
                        const dataSigBytes = await n.sign(dataBytes);
                        const dataSigBase64 = base64.encode(dataSigBytes);

                        // @ts-ignore
                        for (const conn of n.conns.Iter()) {
                            conn.Send(`${dataBase64}.${dataSigBase64}`);
                        }
                    } catch (error) {
                        console.log(error);
                    }
                },
            },
        }));
    }

    for (const node of nodes) {
        await node.Wait();
    }
});

[alfnielsen]

Well, I was about to add a new issue, but I guess this issue covers it.

@ts-ignore handles multi-line and single-line imports different!

There are still a lot of npm modules that dont have typings, or are written without NoImplicitAny,
which result in "implicit any" error then they are imported:

import { a, b } from 'MyNonTypedModule' // <-- Implicit any error

So I can use @ts-ignore:

//@ts-ignore
import { a, b } from 'MyNonTypedModule'

But when I work with auto import and formatters like Prettier this happens:
(Formatted by Prettier)

//@ts-ignore
import { 
  a, 
  b 
} from 'MyNonTypedModule' // <-- Still (again) getting the Implicit any error

I can fix it with:

import { 
 a, 
 b
//@ts-ignore
 } from 'MyNonTypedModule'

or

//@ts-ignore-start
import { 
   a, 
   b
} from 'MyNonTypedModule'
//@ts-ignore-end

But then it begins to look like this on single line imports:

//@ts-ignore-start
import { a } from 'MyNonTypedModule'
//@ts-ignore-end
import { b } from 'SomeTypedModule'
//@ts-ignore-start
import { c } from 'SomeOtherNonTypedModule'
//@ts-ignore-end

So I have to write it like this because auto import's and formatting will change between single-line and multi-line import depending on how many elements that are imported from the module.
It really defeats the purpose of auto import if I have the change the import code manually.

It would be good not to have to write ts-ignore-start and ts-ignore-end on every single imports,
So: //@ts-ignore for the import (not just the next line) is in my opinion something that ts-ignore should handle. (Or some other ignore like: @ts-ignore-block / @ts-ignore-import )

[zpdDG4gta8XKpMCd]

i need to suppress certain errors in the entire file:

// @ts-ignore-all TS1206

/*
... rest of the file
*/

[kylebebak]

In agreement with the folks above that suggested // @ts-ignore-start and // @ts-ignore-end comments to handle use cases mentioned in this thread.

This is nice, because it looks very similar to the current // @ts-ignore directive, and it allows you to of ignore all errors in a file with just the // @ts-ignore-start directive at the top.

[qgates]

There are positive use-cases for a number of the above suggestions. I propose:

@ts-ignore as present behaviour
@ts-ignore TSxxx [TSxxx ...] suppress specific error(s)
@ts-ignore-start start block to ignore
@ts-ignore-start TSxxx [TSxxx ...] suppress specific error(s) for block
@ts-ignore-end end block
@ts-ignore-all suppress errors for rest of file
@ts-ignore-all TSxxx [TSxxx ...] suppress specific error(s) for rest of file

"Specific errors" could include named groups similar to those in tsconfig or user-defined groups of TSxxx errors.

I'm not certain about the value of ignore blocks nesting imported modules; my preference would explicit ts-ignore blocks within imported module files. But when importing 3rd party libs there may be reasons for this so I'm on the fence here.

[xgqfrms]

the .tsignore file wanted

just like .npmignore & .gitignore

[arif-b-khan]

There should be ignore block. I got stuck with puppeteer framework. In puppeteer you've "evaluate" method which allows you to run arbitrary script block on a page. This arbitrary script block could contain reference to functions which are available on the page in other words function reference would be available at runtime.

[tomholub]

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

This will be extremely handy when working with chunks of legacy code, making it less painful to folks to switch to TypeScript.

[Blanen]

About

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

I made this suggestion earlier and kind of want to change the syntax.
Either make it start-stop or begin-end
start and end (as verbs) aren't antonyms and this would bother me forever if it got into typescript.

[tomholub]

That's cool with me

// @ts-ignore-begin
// @ts-ignore-end

[szenadam]

Highly needed functionality.

[adonig]

Why is this still not possible? :-(

[paveldvorak5]

I need block ignore too

[autumnfjeld]

+1

[yuexing0921]

+1

[Felix-Indoing]

any update on this?

[sturmenta]

🙏🏻

[sturmenta]

And if we do it the same as we normally do with eslint?

/* @ts-disable */

!function(){
  // no ts here!
}()

/* @ts-enable */

[Franziskus1988]

As mentioned above: As soon as you are generating TS code (e.g. with swagger) where e.g. unused vars might occur, you need this feature.

[kashesandr]

+1

[captain-yossarian]

Without //@ts-ignore-file it is impossible to migrate to TS

So, it is Without Anybody Noticing not true

[jwvance]

@RyanCavanaugh The community clearly has a need for this, is there a reason this hasn't been addressed? Thanks!

[awitherow]

I am struggling with this right now as I can't even play around with getting a solution working to see if it is even feasable without Typescript crying and blocking my render.

[mrttrifork]

We are currently in need of this feature.

We are importing a public library which has Node types for some functions that we aren't interested in. So it would be nice to use // @ts-ignore for a single import, instead of using skipLibCheck to ignore all the libs.

Initially i liked // @ts-ignore-file idea, but // @ts-ignore would probably work better for the sake of consistency.

[weswigham]

So.... I opened #33383 with support for //@ts-nocheck in typescript files. Now, us being the _TypeScript_ compiler team, we don't really get it, ourselves (not fixing likely problems, whaaaat!!?!?) - even //@ts-ignore in typescript only became a thing because our arm was twisted a bit, so we're.... hesitant... to add further suppression mechanisms. So if y'all really feel such a broad suppression mechanism is required, it'd be nice if you could go over there and 👍

[carpben]

@weswigham, While this is probably not the most important of features. It could be handy during development. Just like temporary commenting a few lines of code, it could be helpful while developing and trying to isolate a problem elsewhere. I would however like to get a warning so this practice won't find it's way to actually cause run time bugs. Perhaps even enable this feature for development only, but to throw an error on build.

[kumar303]

Since this issue is still labeled "Awaiting More Feedback," here's more:

When quickly prototyping new architectural directions, I'd like to do so guided by TypeScript, to make sure the new architecture will work. However, I want to temporarily ignore type errors in unit test files, just temporarily, while I experiment.

Adding some kind of @ts-ignore- comment at the top of each file would be easy enough.

[andrastothtw]

I second @kumar303's need: in unit testing it is beneficial to turn off some check for that given block/file, since it will be the assertions that will cover those cases.

[Blanen]

@weswigham You could put it behind a compiler flag.

[weswigham]

You could put it behind a compiler flag.

No need - it's in the 3.7 beta.

[kumar303]

re: https://github.com/microsoft/TypeScript/pull/33383 : @weswigham that's great, thanks! A powerful use case here is to temporarily ignore type checking in a file so I suggest also to ship a lint rule that fails when one forgets to remove @ts-nocheck

[ambroiseRabier]

Having an issue on gatsby, where a static graphQL query work in .jsx files, but not in .tsx files. I think this proposition could be a more accetable work-around. (issue here https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5)

[espipj]

Hey!
Has the proposed solution been implemented?

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

I think it would be highly beneficial. I wouldn't mind working on it.

[weswigham]

We added support for //@ts-nocheck for to suppress all errors in an entire file in 3.7. I think that line-level and file-level suppression can encompass _most_ needs without much fuss. If you have a sufficiently large block within a checked file which should be unchecked, maybe just disable checking for the whole file or, should that be distasteful, extract the unchecked chunk to its own file and disable checking for that file or, failing that, suppress each line with an actual issue? A ts-ignore is supposed to ignore a single problem, while a ts-nocheck is supposed to ignore a single file - a range-based suppression doesn't actually map to a specific unit in any way, so seems somehow worse (since it can't be mapped to a single issue or root cause you're suppressing). At least without error-code specific suppressions, I'm not particularly comfortable with range-based suppressions.

I, at least, would prefer a single suppression (//@ts-nocheck File is a legacy untyped UMD module concatenated into the build - declarations are pulled from node_modules, so errors here are hopefully meaningless) at the top of the file or individual suppressions (//@ts-ignore The TS compiler doesn't support the assignment on the next line because we never declare it, but we provide this for legacy compat) on each individual bad thing(tm). I cannot, for the life of me, come up with a compelling, principled example where specific _ranges_ of code should be allowed to be unchecked (unlike files, which had a clear migration-strategy-backed reasoning), other than "writing multiple consecutive suppressions makes my eyes bleed", to which I have _zero_ sympathy for as, fundamentally, we believe you shouldn't be using suppressions in TypeScript at all. If it's a type issue, you can cast out of it (that's why any, casting, and shorthand module declarations exist). If it's a syntax issue, everything is awful and we'll be broken anyway, so suppressions won't do anything (suppressions do not affect parse errors).

[piotr-cz]

Thanks for //@ts-nocheck, but this doesn't resolve problem of disabling check for code block:

const $element = document.createElement('iframe')
$element.loading = 'lazy' // Property 'loading' does not exist on type 'HTMLIFrameElement'.

[Hussain-Ruhullah]

// @ts-nocheck

[rogerfar]

I have an interesting usecase.

We built or own ORM in Typescript that uses acorn to compile statements into our DDL.

To do a where query we have to pass it scoped variables:

.entities
.include('parent')
.where(m => m.id === this.id, { id: this.entityId })
.toList()

This doesn't work simply because: Property 'id' does not exist on type 'xxx'

If I wrap it in @ts-ignore-start it will work fine like this:

// @ts-ignore-start
.where(m => m.id === this.id, { id: this.entityId })
// @ts-ignore-end

But when the formatted comes by and starts adding line breaks:

// @ts-ignore-start
.where(m => m.id === this.id || m.id === this.id2, {
  id: this.entityId,
  id2: this.entity2Id
})
// @ts-ignore-end

It doesn't work anymore.

[weswigham]

This doesn't work simply because:

That's exactly the kind of type-level error you should just have an as any cast (or, in jsdoc, /** @type {any} */(expr)) on the access(es) for, if you really want to suppress it.

[Inframatic]

//@ts-nocheck doesn't work for my ts angular project but //@ts-ignore does. This issue for microsoft started in 2017. 2017! wow...

[hatchli]

3 Years now and no solution. Unsurprising that may JavaScript developers don't want to make the jump to typescript

[Noxware]

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

Any plans to implement this?

[jpomykala]

// @ts-nocheck
is the only option currently :(

[drumminj]

Another use case to add for consideration here...

I am code generating a bunch of TypeScript code from an in-house markup language that allows some basic control flow and conditionals. While I control the code generation behavior, I do not control the inputs passed to the code generator (that is up to end users)

As a result, the code generated may easily have unreachable code, or in one case TS2367 as there may be nested code which tests a value against an enum constant, then inside that block contains another check of that variable against another enum constant. For example:

if (foo === MyEnum.ONE) {
  const bar = (foo === MyEnum.TWO ? "two" : "one");
}

With hand-written code, this pattern is easy to fix and avoid. With code generation, however, it's up to my users (developers, you know the type!) to not provide input that unnecessarily tests for impossible values.

I do not wish to disable typechecking outright, but I have no other mechanism to consume the code-generated code due to this error. Ideally I'd suppress this one error for all code-generated files, but retain all other type checking.

As it is, I don't have a solution other than turning off all type checking. At which point I'm not getting much value out of TypeScript vs plain JavaScript

[ivnnv]

Are you serious? This stills an open issue and not implemented in TS4 ? 🤦🏽

[ndraiman]

@ivnnv You can use // @ts-expect-error in TS 3.9, see here

[ivnnv]

@ndraiman @ts-expect-error works for individual lines but not for blocks, so it is still needed to place many of those if one wants to "ignore a block"

[MathiasKandelborg]

Here's some more feedback for you:

What else do you need? What does the community have to do to get this functionality?

The best use case for this is the alternative to writing any on every single type one is making. You might not have sympathy for aesthetics (which no doubt has an impact on mood and productivity), but just having an alternative that matches the common expectations shouldn't be hard to accept.

People have different views on what is acceptable and what isn't.

To some people, it is too time-consuming and limits the flow-state people can be in while doing mundane stuff like porting code.
I find it annoying and weird that I can't have an ignored block of code but instead have to litter it with any casts, which often has a detrimental effect on readability (until the proper types are there). Having to continually write a new comment or indulging in a distraction _just because someone doesn't see the benefit of ignoring blocks of code_ is not okay in my perspective.

EXAMPLE:

One is porting a project from JS to TS, with the other project being developed by a third-party.

The syntax and rules followed in the ported project can be either old e,g, es2015, or deprecated in favor of clearer syntax and less code, etc.

When porting this project, some of the code might be extremely easy to port to TypeScript. Still, one inevitably runs into, e.g., half-thought through booleans and functions with arbitrary behavior that either needs more context or has to be thought about for some time to create its types.

It would be so awesome to stop checking a function or a block of code in a file while fixing it. Ignoring a code-block would enable one to move quickly in the areas they know and are comfortable with and save certain parts for later.

My workflow when I have to port JavaScript to TypeScript (and the code is, well, subpar):

1. Copy code from .js to .ts file.
2. See if TS can infer any types by usage
3. Manually understand types from usage
4. Realize errors are the bane of my existence
5. Try to comment out errors, thereby improving the number of lines in the file sometimes x3 ESLlint + TS (more is better?)
6. Remove and add// @ts-check at the top while carefully editing the rest of the files & add more types.

If we could ignore blocks:

1. Copy code from .js to .ts
2. See if TS can infer any types by usage
3. Manually understand types from usage
4. // @ts-ignore-enable ... // @ts-ignore-disable individual functions & troublesome code-blocks
5. Uncomment blocks as I get to them and add types

Decide for yourself what seems most reasonable. It's the same when porting JS to a project with way more ESLint rules, and you have to refactor most stuff.

I wish we could do like it's possible in ESLint and use /* eslint:disable */ ... /* eslint:enable */ in TypeScript.

P.S I just realized when checking this comment that I've spent 20 minutes+ trying to get an experience I (and many others) have been seeking since 2017, just to comment on a soon 3-year-old open issue.

[MathiasKandelborg]

@weswigham @RyanCavanaugh

Reminder :+1:

[agusterodin]

Will give firstborn in exchange for this

[ShuiRuTian]

@agusterodin Your sacrifice attracts the attention of evils.....

Alright, nothing happens in fact, except I just give a simple PR :)

However, personally, I do strongly aggree with TS team's opinion -- this function is evil, you should always try to avoid using @ts-ignore, not to use @ts-ignore-enable(or @ts-ignore-start, whatever).
But sometimes, you know, the proverb says drinking posion to satisfie thirst, I know it is a bad choice, but it is just in need.

---

edit: add explain and examples.
This PR add two directives ts-ignore-enable and ts-ignore-disable.

1. if only use ts-ignore-enable, the rest part is all ignored.

...   <-- this is normal
// @ts-ignore-enable
XXX    <-- this is ignored
...    <-- this is ignored

1. you could add same directives for many times, but they only work for once.

// @ts-ignore-enable
XXX  <-- this is ignored  
// @ts-ignore-enable       <-- you could remove this line.
YYY   <-- this is ignored
// @ts-ignore-disable
ZZZ   <-- this is normal
// @ts-ignore-disable      <-- you could remove this line.

1. // @ts-ignore-disable could be used alone, nothing would happen.

2. @ts-expect-error would not work in the ignored region

// @ts-ignore-enable
XXX  <-- this is ignored
// @ts-expect-error       <-- No error message. whatever next line has error or not.
YYY   <-- this is ignored

1. no region label, they are just comment.

// @ts-ignore-enable A
XXX  <-- this is ignored  
// @ts-ignore-enable   B    <-- you could remove this line.
YYY   <-- this is ignored 
// @ts-ignore-disable B
ZZZ   <-- this is normal
// @ts-ignore-disable A     <-- you could remove this line.

[MathiasKandelborg]

In a perfect world, we wouldn't need to ignore type safety, right? :sweat_smile:
I need it when copying fantastic work e.g., examples and starters, even the occasional SO answer that isn't typed or typed as I'd want. Mostly to have it in my type-safe code that follows my settings. I just use very strict settings and often have to rewrite a function or some logic because of that. It's not because I want to keep ignoring that block of code, that wouldn't make sense.

Ignoring a block of code is a convenience, that to me, seems perfectly reasonable given the fact I still can @ts-ignore every line in a block.

I understand the possible implications this could have for people going I'll just ignore this because it's easier. As I see it, anyone who could use block scope ignores to drink poison to satisfy their thirst is already drinking drops of poison with @ts-ignore.

[mohsen1]

Now that you can do @ts-nocheck in .ts files, I suggest allowing @ts-check in .ts files as well so we can turn off/on the type checker:

import fs from 'fs'

fs.readFileSync(32423) // type checking

// @ts-nocheck
fs.foobarbaz() // type checking is off
fs.__randomThing()

// @ts-check
fs.readFileSync(123) // now type checking again

This doesn't require defining what a "code block" is. You can start and stop type checking from - to any line.

[kumar303]

UPDATE I was mistaken, see https://github.com/microsoft/TypeScript/pull/40267#issuecomment-713840095 for the correction.

When trying to migrate an app using styled-components to TypeScript, I ran into a problem where @ts-ignore can't be used above template strings (for some reason). This was a bummer because my only option was to fix errors or use @ts-nocheck on the whole file. It could have been solved with an ignore-block.

Example of the TS error I was trying to ignore:

import styled from "styled-components";
import { Button } from "...";

// @ts-ignore here does not work
const StyledNavBar = styled.div`
  ${Button} {
    margin: auto 0;
  }
`;

[MathiasKandelborg]

As an extra note: I can't cast any in my TS project, I don't allow any types. What is the recommendation then?

@weswigham What are your thoughts on flow-state, and productivity in context to aesthetics? It seems you don't have any sympathy for bleeding eyes; but do you have any notions about productivity, porting code, and the processes I described? Do you still not see any benefit _at all_, after considering my comment, and in the context of being more productive? I also described some real situations where one would need block scope ignoring. Furthermore, how does this functionality not compare to ESLint and the functionality we expect there?

It is scientifically proven that fewer interruptions increase productivity and enhances efficiency; block scope ignoring would enable fewer interruptions when porting code. Does the TS team not realize that "fundamentally, we believe you shouldn't be using suppressions in TypeScript at all." is an opinion based on living and breathing TypeScript, and that in the real world, people need to port poorly written code to other codebases, with more type safety and other linting rules; in those situations, it does not make sense that you can ignore a file or a line, but not the block of code you just imported.

To me, it seems like you're going for utopia while ignoring reality. @sandersn You didn't address any of my points and hold the old response over newer discussions in the case. You also state that unless the team decides otherwise, it shouldn't be implemented, in which case: close the issue?

The team either needs to make a decision or implement a clearly wanted feature.

Keeping the issue in limbo does not make any sense.

[RyanCavanaugh]

I'm sorry we can't give you the finality you need, but the reality is that "maybe later" is an answer that you are going to have to learn to live with. Any given feature can't be rushed into the product tomorrow, and for features that fall within our design parameters, there are thousands of currently-open suggestions that are competing for our capacity to add them to the product in a way that is ergonomic, useful, stable, and forward-thinking.

We prioritize things based on current feedback, the state of current solutions and workarounds, the preponderance of those scenarios, tooling, and a hundred other factors. Things that are not high-priority right now can become high-priority later. That is the nature of "maybe later" and I think that is an accurate representation of where this suggestion stands. The decision here, for now, is to continue to monitor the feedback and understand what people are running into that might necessitate this feature as being higher priority than any other feature we might add next, of which there are hundreds competing for attention.

The tone here is honestly trending towards hostile and speaking personally, being shoved toward an ultimatum is not conducive to a constructive conversation that helps us understand where this is adding value that outpaces its complexity relative to the alternatives.

[MathiasKandelborg]

I am sorry about setting an ultimatum. I got quite annoyed to see activity toward the PR, but none on the issue. I agree that my previous comment doesn't contribute in any constructive way.

I can accept that this issue might need to wait. I provided some feedback and have asked what other feedback is necessary to move closer to resolution, but I got no response. It seems, however annoying it may be, that my rather unconstructive comment was what I needed to do to get _some_ response from the team.

It still seems that no actual progression toward an issue with over 700 positive reactions, that is several years old, has been made. I do not believe it should go faster, but it seems like the team is disinterested in exploring this feature since members have personal opinions against it. I completely understand all of these things. That's not what I'm on about here, though. I want to get some conversation going, but I am being ignored.

I would like to know that my feedback is considered, and given the nature of it, responded to. It's not a big disruption in the feature-set, shown by the active PR that got whipped up in a short amount of time. Everything is ready to go, people keep reacting positively toward resolving this issue with a block ignore feature, and I chimed in asking what the community has to do to get this feature. I strongly disagree with several of the points being made from the team and have argued against it, a PR was made and a comment given stating that 'unless we change our minds' nothing will change.

That's where my frustration comes to surface. You want to disregard a ready feature because no changes have been made toward a decision from a team member, completely ignoring my own and other people's feedback.

It seems that unless someone on the team decides otherwise _on their accord_, we won't see any changes on this issue. That does not call for more feedback from the community, does it? That's why I wrongly made the ultimatum.

I have made several arguments against @weswigham's points, provided some examples, and am honestly still waiting for some kind of response to it. The only thing that seemed to help was being visibly upset and unconstructive.

How do we move from here? What feedback would the team like? It seems like a personal issue hidden behind "We prioritize things based on current feedback, the state of current solutions and workarounds, the preponderance of those scenarios, tooling, and a hundred other factors." since several people have tried giving feedback with no response _at all_ from the team.

I would like to reiterate that I understand that this might not be a high priority if we take people's opinions away from the subject. At the same time, the feature is ready to be implemented, and arguments have been made. What is needed now is for the team to make a decision/response (not necessarily implement anything) and make it public. If that's not what is required, then please tell me what is, or how one would help heighten the priority on _any_ feature or issue for TypeScript, but especially this one.

[gamtiq]

Another use case for multiline (@ts-ignore-start+@ts-ignore-end) or inline (like /* @ts-ignore */) @ts-ignore.
Environment:

• "noUnusedParameters": true
• Enabled ESLint require-jsdoc rule.
• Code similar to the following (simplified example):

type Data = Record<string, unknown>;
type PrepareSettings = Record<string, unknown>;

/**
 * This is base class that will be inherited.
 */
class SuperClass {
    /**
     * Prepare data for further usage.
     * 
     * @param data
     *      Data that should be prepared.
     * @param settings
     *      Operation settings.
     */
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {
        return data;
    }

    // Some additional methods...
}

For the described situation TypeScript emits the following warning: 'settings' is declared but its value is never read.(6133).
It is possible to suppress the warning by adding @ts-ignore after end of the documentation comment:

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {

But after that ESLint will complain about Missing JSDoc comment.
So the solution is:

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {   // eslint-disable-line require-jsdoc

Which is awkward and ugly.

[MathiasKandelborg]

@RyanCavanaugh @weswigham @sandersn

A monthly reminder that this is something the community wants to discuss further with the TypeScript team. There's a lot of support and what's currently missing is a response from the team. I get that there's a lot of prepondering, and progressing TypeScript is no easy feat. Things take time. Since there's no response regarding how we can further this suggestion and get some more direct action taken, I will make a reminder like this regularly. I am not giving up until a decision has been made, and commenting seems to affect (mostly when being an !@# though).

[JerryGreen]

After these years passed, though I was originally freaked out how this functionality isn't there, I personally rethought it a little bit... When there's a huge bunch of @ts-ignore, you may already tell that there's something wrong with your code, and spend some time on improving your types. We all are pretty lazy sometimes, and want speed in overall, but currently it's often easier to figure out few proper types rather then copy-pasting multiple @ts-ignore into big bunches of code. If this balance of INconvenience will be broken, many of us will be conveniently abusing @ts-ignore-enable, which might only decrease overall quality of all little open source projects here and there.

Btw, though we see that there are many 👍 reactions on this issue, - it might be biased, because whole lot more people might feel completely fine without this feature while being silent, because they're not here.

[MathiasKandelborg]

@JerryGreen Referencing my older comments, I have said the exact same thing. With the addition that people are already doing this with the ignore feature. There's no reason to implement a little bit of poison all the while claiming there should be _none_.

Either remove the @ts-ignore functionality or make it fully-fledged. There are many arguments to do this, and people writing bad code will continue using @ts-ignore which is just as bad as a block ignore feature, they are the exact same thing - except for block ignoring being less visually disruptive.

The community still needs a response from the TypeScript team.

[L-Hknu]

@JerryGreen Referencing my older comments, I have said the exact same thing. With the addition that people are already doing this with the ignore feature. There's no reason to implement a little bit of poison all the while claiming there should be _none_.

Either remove the @ts-ignore functionality or make it fully-fledged. There are many arguments to do this, and people writing bad code will continue using @ts-ignore which is just as bad as a block ignore feature, they are the exact same thing - except for block ignoring being less visually disruptive.

The community still needs a response from the TypeScript team.

Some special scenarios still need to use @ TS ignore. For example, CDN import does not depend on node_ The. TS file does not exist in the modules scenario

[MathiasKandelborg]

@L-Hknu Thanks for clarifying. People use it as they use ignores with ESLint anyways.

The ignore functionality is not disallowed in contexts besides where it's needed for functionality. That tells me it's okay to use it to ignore code.

I still can't reason why there should be no block ignore, as it is used in the same way most of the time.

I have ditched converting to types for some open source code, because the progress of converting would have been so much more comfortable with block ignores. I don't need it, but I think many people will get a foot inside the door with typing; furthermore, many people would most likely contribute to conversions more efficiently, especially given how different the aesthetics are between block and every-line comments.

[PatricNox]

My biggest use case for this implementation would be for third-party packages which doesn't have typescript support, and I'd need to ignore some of its uses.

[L-Hknu]

@L-Hknu Thanks for clarifying. People use it as they use ignores with ESLint anyways.

The ignore functionality is not disallowed in contexts besides where it's needed for functionality. That tells me it's okay to use it to ignore code.

I still can't reason why there should be no block ignore, as it is used in the same way most of the time.

I have ditched converting to types for some open source code, because the progress of converting would have been so much more comfortable with block ignores. I don't need it, but I think many people will get a foot inside the door with typing; furthermore, many people would most likely contribute to conversions more efficiently, especially given how different the aesthetics are between block and every-line comments.

It looks like it's done
#40267