GeezerVison

TypeScript Bot (@typescript-bot) pack this

Heya Wesley Wigham (@weswigham), I've started to run the tarball bundle task on this PR at 459196b. You can monitor the build here.

TypeScript Bot (@typescript-bot) pack this now that baselines should be green again :)

Heya Wesley Wigham (@weswigham), I've started to run the tarball bundle task on this PR at 97bba40. You can monitor the build here.

Is this opt-in only, or will it be possible to opt-out as well?

You should be able to write things like // @ts-strict false and the like. Parameters get parsed the same way they do on the command line.

TypeScript Bot (@typescript-bot) pack this

Heya Wesley Wigham (@weswigham), I've started to run the tarball bundle task on this PR at ef3813c. You can monitor the build here.

Hey Wesley Wigham (@weswigham), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/129711/artifacts?artifactName=tgz&fileId=07F2813C225AA6CC371299076DC3BF08FFE79A5C45BC00165AB9D270F70FC3FB02&fileName=/typescript-4.8.0-insiders.20220713.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;

This should be cleaned up and ready to go, so let's get the bot to do some tests on this iteration (not the much has changed implementation-wise since I ran them on the strict null checks-dedicated draft pr).

TypeScript Bot (@typescript-bot) pack this
TypeScript Bot (@typescript-bot) user test this inline
TypeScript Bot (@typescript-bot) test this
TypeScript Bot (@typescript-bot) run dt
TypeScript Bot (@typescript-bot) perf test this

Heya Wesley Wigham (@weswigham), I've started to run the extended test suite on this PR at 4bde2e7. You can monitor the build here.

Heya Wesley Wigham (@weswigham), I've started to run the perf test suite on this PR at 4bde2e7. You can monitor the build here.

Update: The results are in!

Heya Wesley Wigham (@weswigham), I've started to run the abridged perf test suite on this PR at 5b77328. You can monitor the build here.

Update: The results are in!

Wesley Wigham (@weswigham)
The results of the perf run you requested are in!

Hi, any updates on this? Now that it is approved, can we expect it to be merged anytime soon?

TypeScript Bot (@typescript-bot) pack this

Hey Wesley Wigham (@weswigham), if you don't mind, can you please ask the TypeScript Bot (@typescript-bot) to pack this latest iteration? It seems to listen to the PR author. I wanted to try it out in some local project. Thanks!

TypeScript Bot (@typescript-bot) pack this

Heya Jake Bailey (@jakebailey), I've started to run the tarball bundle task on this PR at 5b77328. You can monitor the build here.

Hey Jake Bailey (@jakebailey), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/142539/artifacts?artifactName=tgz&fileId=84F197BAEF8A6E106505CC1E9EE470B6D941DF8AA3E6B9D2787B60D6817BEDF002&fileName=/typescript-4.9.0-insiders.20230113.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;

Thanks Jake Bailey (@jakebailey)!

There is only a week before ts 5.0 beta. Maybe this feature will be avaliable after 5.1

I'm seeing these kinds of errors despite turning off the check. Is this expected? Ideally it should not be imo as turning off SNC from tsconfig would not generate this error.

Playground Link

I was writing up a much longer background for this, but I’m exhausted on Saturday, and don’t want to lose the context before I bail. I’m happy to come back and fill in details of why I’m asking if it seems really bonkers to ask.

Is there any possibility this could allow specifying:

• tsconfig path rather than individual config items
• a range of lines it applies to versus a whole module

The use case prompting me to ask involves using Playwright as a library, and would incredibly simplify its usage (and type safety) for a single function proxy as I transition a library from dependence on Node APIs and native dependencies to be usable in browser. It’s definitely not a common use case, but I can imagine others which might benefit from specifying a given callback is being shuttled off to be executed in an entirely different environment.

Hey all, the future of this feature is somewhat uncertain. Any time the type system has to make a decision based on strictness, it now has to walk up to the top of the file and check for strictness directives. If not that, every node (or almost every node) of our syntax trees has to get a little bit bigger to hold onto that information.

This has a type-checking performance impact that is higher than we can accept. There might be some optimizations we can make for the more common case of no file-specific options within a project, but that leads to some unpredictable performance cliffs as soon as one is added.

So this won't make its way into TypeScript 5.0, and it's unclear if we'll be able to bring it in in the future either.

Hey all, the future of this feature is somewhat uncertain. Any time the type system has to make a decision based on strictness, it now has to walk up to the top of the file and check for strictness directives. If not that, every node (or almost every node) of our syntax trees has to get a little bit bigger to hold onto that information.

This has a type-checking performance impact that is higher than we can accept. There might be some optimizations we can make for the more common case of no file-specific options within a project, but that leads to some unpredictable performance cliffs as soon as one is added.

So this won't make its way into TypeScript 5.0, and it's unclear if we'll be able to bring it in in the future either.

Can this option be not added as an opt in? like an option in compilerOptions something like "enableIncrementalStrictCheckComments" or something? this can be an incredibly helpful option I think most people would be happy to accept a performance penalty to allow for incremental migration to safer and better code.

I came across this issue searching for a way to enable incremental strict checks on a 50k+ line codebase on which enabling strict checks throws up 3k+ errors 🙈 while i understand plugins exist for this having this on a compiler level can be so much better!

I know no nothing about typescripts development process/priorities so if anything i said here is wrong/doesnt make sense I apologise but I sincerely hope you consider the request!

Thank you to the author and typescript team for their time and effort on this!

Wesley Wigham (@weswigham) is this worth keeping open? Is it worth revisiting in Go?

Please consider adding this as an opt in option like Debadree Chatterjee (@debadree25) mentioned.

Also im not sure that compiler performance is something that should be optimised for and chosen above this feature, considering the whole point of TS is to optimise for safely typed code? and especially considering the recent improvements after migration to go.

Also, surely you just do a single pass of all the files and store their strictness directives in a hashmap?? so that you dont walk the tree on every single check?

Id pay the one time incremental reduction in compilation time any day over having to live with strictNullChecks: false in the project forever.

as it stands, migrating from non-strict to strict compilations is not a feasible task within a large active project with competing priorities.

The rate of new work being developed by many developers with non-strict ts config, is greater than the amount of files that can be incrementally refactored to strict-checks by whatever developer is spearheading the operation.

having the ability to enforce // Strict TypeScript (@ts-strict) at the top of any new file commits would go a long way in making a migration like this feasible

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate