Skip to content
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

Open
zpdDG4gta8XKpMCd opened this issue Oct 30, 2017 · 55 comments

Comments

@zpdDG4gta8XKpMCd
Copy link

@zpdDG4gta8XKpMCd zpdDG4gta8XKpMCd commented Oct 30, 2017

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

@zpdDG4gta8XKpMCd zpdDG4gta8XKpMCd changed the title @ts-ignore for the block scope @ts-ignore for the block scope and imports Oct 30, 2017
@bluelovers

This comment has been minimized.

Copy link
Contributor

@bluelovers bluelovers commented Feb 5, 2018

need this lol

@jeahyoun

This comment has been minimized.

Copy link

@jeahyoun jeahyoun commented May 22, 2018

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

This comment has been minimized.

Copy link

@DrSensor DrSensor commented May 25, 2018

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

This comment has been minimized.

Copy link

@ptallett ptallett commented Jul 1, 2018

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

This comment has been minimized.

Copy link
Member

@DanielRosenwasser DanielRosenwasser commented Jul 2, 2018

@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

This comment has been minimized.

Copy link

@ExoMemphiz ExoMemphiz commented Aug 9, 2018

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

This comment has been minimized.

Copy link

@anodynos anodynos commented Oct 10, 2018

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

This comment has been minimized.

Copy link

@jnwu jnwu commented Oct 10, 2018

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

This comment has been minimized.

Copy link

@dwilhel1 dwilhel1 commented Oct 23, 2018

Also seeking an update on this request. Thanks!

@MayaWolf

This comment has been minimized.

Copy link

@MayaWolf MayaWolf commented Nov 2, 2018

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

This comment has been minimized.

Copy link

@pungggi pungggi commented Dec 1, 2018

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

@mszczepanczyk

This comment has been minimized.

Copy link

@mszczepanczyk mszczepanczyk commented Dec 10, 2018

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

This comment has been minimized.

Copy link

@marianturchyn marianturchyn commented Dec 17, 2018

/* tslint:disable */

code

/* tslint:enable */

@Blanen

This comment has been minimized.

Copy link

@Blanen Blanen commented Dec 17, 2018

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

This comment has been minimized.

Copy link

@lonix1 lonix1 commented Jan 25, 2019

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

This comment has been minimized.

Copy link

@mgol mgol commented Jan 25, 2019

@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

This comment has been minimized.

Copy link

@lonix1 lonix1 commented Jan 25, 2019

@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

This comment has been minimized.

Copy link

@mgol mgol commented Jan 25, 2019

@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

This comment has been minimized.

Copy link

@matthiasg matthiasg commented Feb 4, 2019

@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

This comment has been minimized.

Copy link

@fgcui1204 fgcui1204 commented Feb 14, 2019

Need this feature.

@haggholm

This comment has been minimized.

Copy link

@haggholm haggholm commented Feb 14, 2019

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

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Feb 14, 2019

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

@haggholm

This comment has been minimized.

Copy link

@haggholm haggholm commented Feb 14, 2019

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

@qgates

This comment has been minimized.

Copy link

@qgates qgates commented Jun 3, 2019

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

This comment has been minimized.

Copy link

@xgqfrms xgqfrms commented Jun 6, 2019

the .tsignore file wanted

just like .npmignore & .gitignore

image

@arif-bannehasan

This comment has been minimized.

Copy link

@arif-bannehasan arif-bannehasan commented Jun 7, 2019

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

This comment has been minimized.

Copy link
Contributor

@tomholub tomholub commented Jun 25, 2019

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

This comment has been minimized.

Copy link

@Blanen Blanen commented Jul 1, 2019

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

This comment has been minimized.

Copy link
Contributor

@tomholub tomholub commented Jul 1, 2019

That's cool with me

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

This comment has been minimized.

Copy link

@szenadam szenadam commented Jul 2, 2019

Highly needed functionality.

@adonig

This comment has been minimized.

Copy link

@adonig adonig commented Jul 11, 2019

Why is this still not possible? :-(

@paveldvorak5

This comment has been minimized.

Copy link

@paveldvorak5 paveldvorak5 commented Jul 29, 2019

I need block ignore too

@autumnfjeld

This comment has been minimized.

Copy link

@autumnfjeld autumnfjeld commented Aug 1, 2019

+1

1 similar comment
@yuexing0921

This comment has been minimized.

Copy link

@yuexing0921 yuexing0921 commented Aug 1, 2019

+1

@Felix-Indoing

This comment has been minimized.

Copy link

@Felix-Indoing Felix-Indoing commented Aug 5, 2019

any update on this?

@sturmenta

This comment has been minimized.

Copy link

@sturmenta sturmenta commented Aug 5, 2019

🙏🏻

@sturmenta

This comment has been minimized.

Copy link

@sturmenta sturmenta commented Aug 5, 2019

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

/* @ts-disable */

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

/* @ts-enable */
@Franziskus1988

This comment has been minimized.

Copy link

@Franziskus1988 Franziskus1988 commented Aug 6, 2019

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

This comment has been minimized.

Copy link

@kashesandr kashesandr commented Aug 16, 2019

+1

@SerhiiBilyk

This comment has been minimized.

Copy link

@SerhiiBilyk SerhiiBilyk commented Aug 19, 2019

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

So, it is Without Anybody Noticing not true

@jwvance

This comment has been minimized.

Copy link

@jwvance jwvance commented Aug 24, 2019

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

@awitherow

This comment has been minimized.

Copy link

@awitherow awitherow commented Aug 24, 2019

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

This comment has been minimized.

Copy link

@mrttrifork mrttrifork commented Sep 11, 2019

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

This comment has been minimized.

Copy link
Member

@weswigham weswigham commented Sep 11, 2019

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

This comment has been minimized.

Copy link

@carpben carpben commented Sep 12, 2019

@weswigham, While I don't consider this feature to be important, I registered to this discussion since I think it could be handy. Like console.log and temporary commenting a few lines of code, this isn't something that should find it's way to production, but could be helpful while developing and trying to isolate a problem elsewhere. One common example is creating and drafting new file, not completing it's implementation, then moving on to other tasks. 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, not for production.

@kumar303

This comment has been minimized.

Copy link

@kumar303 kumar303 commented Sep 12, 2019

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

This comment has been minimized.

Copy link

@andrastothtw andrastothtw commented Sep 17, 2019

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

This comment has been minimized.

Copy link

@Blanen Blanen commented Oct 2, 2019

@weswigham You could put it behind a compiler flag.

@weswigham

This comment has been minimized.

Copy link
Member

@weswigham weswigham commented Oct 2, 2019

You could put it behind a compiler flag.

No need - it's in the 3.7 beta.

@kumar303

This comment has been minimized.

Copy link

@kumar303 kumar303 commented Oct 2, 2019

re: #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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.