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

[MayaRainer]

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