noImplicitAny is a great way to migrate a large code base, but allow per type override

[robin-anil]

We migrated a large codebase and we are gradually typing the entire codebase. This is a feature request to build a way to disallow implicitAny for a given type or a set of types so that we can make new code strict while keeping legacy code implicitAny, so that we can make things strict one type at a time instead of files or classes.

[DanielRosenwasser]

This isn't the first time we've gotten a request like this - for example, there's #8855. As we start to tinker with the idea of error suppression, maybe it's time we revisit this.

[robin-anil]

Yes, that would be helpful. Is the idea of error suppression slated for planned 2.6 ?

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

[robin-anil]

@mhegazy can you link to the bug where it is addressed? Or indicate why it is unactionable. As a user who is not privy to typescript team discussions, it is really confusing

[mhegazy]

@mhegazy can you link to the bug where it is addressed? Or indicate why it is unactionable. As a user who is not privy to typescript team discussions, it is really confusing

This issue has been discussed in #8855. We like to keep the discussion of a topic to one issue. feel free to add your comment/vote to #8855. We intentionally do not lock closed issues to allow users to voice their opinions on closed issues, and we do revisit our decisions based on these comments/discussions.

[robin-anil]

That bug is related but not necessarily a duplicate. Issue #8855 is talking about using it on a per-file basis, but given the way the compilation works, it may be better to do it on a per-type basis. Maybe the distinction was not clear.

If you believe that is still a duplicate, I can stop pushing for it.

[mhegazy]

not sure what you mean by a type here, and you already have index signatures to turn off implicit any errors for accessing and explicit any errors are controlled by an explicit type annotation.

For the migration scenario i understand the per file request, and i believe this is tracked by #8855.

[robin-anil]

Could you clarify what you mean by

you already have index signatures to turn off implicit any errors for accessing

Here I mean if say we can annotate a type say with a strict mode

/* @strict */
interface MyType {
....
}

Then we can be sure that type will never be cast into any type or back implicitly, which happens now with --noImplicitAny=false, I would like to manually annotate types which will never respect noImplicitAny

[mhegazy]

well.. interfaces/types are really not the ones you get the implicit any errors on; usually you do not write a type declaration and leave off the type of its members, e.g. type X = { a; }. it is function/properties/variable declarations. and i would personally find it annoying to go on ever function i have and add @strict. again, i see the per-file option, like some modules have been audited for implicit-any and do not want them to regress, but have no time to do it for all files.