@ts-ignore for the block scope and imports #19573
Comments
zpdDG4gta8XKpMCd
changed the title
mhegazy
added
Suggestion
|
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. |
|
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 |
|
Is this still not possible? I don't understand why populair functionality not gets implemented, it's not like corporations also need this. |
|
#19573 (comment) |
|
I'll replace my previous satirical comment made mostly out of spite to a more serious reason: I need to do a crap-ton of type conversions due to how values are handled in form components utilizing TS and a legacy backend that needs to store yes/no, checkboxes and select fields as numbers. Doing these conversions are a bit wonky one way, but don't trigger any errors, while they do while converting them back again. The code works just fine, but TS can't possibly know that so it shows an error. I can choose to either ignore these errors, completely disable all errors in the file (scary for obvious reasons) or line-by-line tell TS to chill the fuck out. Why not just give us the option to disable errors over multiple lines? We can already do it but it's ugly, so it changes nothing but quality-of-life for those that want to use it. |
|
To anyone with the right permissions, please lock this thread. I wish everyone could flag comments that are out of place so that the thread becomes readable again but GH only provides such a feature for contributors of the repository AFAICT. I feel like the participants here have provided enough 1. workarounds 2. history 3. limitations that this conversation can be locked and serve as a 👍-counter rather than unwarranted noise in (y)our inboxes. |
|
+1 |
and others
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: