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

Strict type-checking on a per-file basis "@ts-strict" #28306

Open
4 tasks done
lukewis opened this issue Nov 2, 2018 · 29 comments
Open
4 tasks done

Strict type-checking on a per-file basis "@ts-strict" #28306

lukewis opened this issue Nov 2, 2018 · 29 comments
Labels
In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@lukewis
Copy link

lukewis commented Nov 2, 2018

Search Terms

strict per file

Suggestion

Currently in the process of converting a moderate-sized javascript project to typescript. Would love to be able to enable strict type-checks on a per-file basis.

Use Cases

Enabling strict mode for the entire project is a daunting task that presents a barrier to adoption (and using typescript without strict mode turned on is like locking the doors on a convertible....it's probably better than nothing, but it's not gonna keep you safe).

Examples

//@ts-strict

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript / JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. new expression-level syntax)
@weswigham weswigham added Suggestion An idea for TypeScript In Discussion Not yet reached consensus labels Nov 2, 2018
@artursvonda
Copy link

Would love to see this feature implemented as well. We have quite sizeable project and going "all strict" is not an option right now.

@lukewis
Copy link
Author

lukewis commented Dec 18, 2018

Worth mentioning.... that I ran across another project (unfortunately I forget which one right now) that had this same need. Their workaround was to use a separate tsconfig file and run TWO builds. The first build was NOT run in strict mode and was responsible for the actual compilation. They would then run a SECOND build using a tsconfig file that whitelisted specific files that were ready to be compiled in strict mode. The second build had noEmit = true, and was used ONLY for type-checking. I still think it's much nicer to have this supported natively, but wanted to at least document the workaround in the meantime.

@rene-leanix
Copy link

We tried to implement this with "local" tsconfig.json-files extending the main tsconfig.json with the strict compiler option and including only specific files or all files within and below that folder, e.g.

{
  "extends": "../../tsconfig",
  "compilerOptions": {
    "strict": true
  },
  "include": [
    "./**/*.ts"
  ]
}

together with the following npm scripts

"tsc-local-tsconfigs": "errors=$(find src/app -name tsconfig.json | xargs -I % sh -c 'tsc -p % | grep error'); echo \"$errors\n\"; [ -z \"$errors\" ] || exit 1;",

The latter we execute on CI to ensure all files specified in local tsconfig.json and their dependencies can be compiled with those settings.
When viewing one of those files in VS Code, the editor automatically uses the tsconfig.json file closest to that file that has matching include/exclude patterns, so errors are shown immediately.

@gerich-home
Copy link

Another example when it can be useful.
I came to a project where TypeScript has been adopted but I found that the team disabled one of strict checks (say "strictFunctionTypes": false,).
The reason (if I set it to true) turns out to be in bad external typings that were used in another (relatively small) part of project. So to avoid this check in a certain place of a large project and to do not introduce castings / any type and etc. they disabled strict check at all.
A better approach would be to disable/enable on per file/per directory basis.
Actually tsconfig has references field, but it involves changes in how the project build procedure works AFAIK (it can be undesirable). Maybe a similar field should be introduced, but that specifies what overrides are applied per directory.

@maxime1992
Copy link

While this would be really awesome in some cases, I've started to use Betterer so that we can progressively improve our code base and avoid regression because a given flag is turned on locally to do some fixes and then off before pushing.

Here's an example: https://dev.to/phenomnominal/stricter-typescript-compilation-with-betterer-dp7

@JohnForster
Copy link

Equally, it would be good to be able to turn it on globally, and then disable for specific files.

@y0nd0
Copy link

y0nd0 commented Feb 4, 2021

In our case, we have a huge app that was written years ago with no strict mode.
Today I want to use strict mode for cleaner code and fewer runtime errors.
But we can't activate it, otherwise the code would shine like a Christmas tree.
It is not very economical to convert all the code at once. It's too complex.
So strict mode per file would be great. ...

@Lakston
Copy link

Lakston commented Feb 9, 2021

I agree, there is no way we can migrate to strict mode in one swoop, we need to be able to do that on a per file basis.

@mrhut10
Copy link

mrhut10 commented Feb 19, 2021

I would love this, or at mainly a way to turn off strict for a particular file.

that way I can inforce team not to ever turn off scrict for whole project, just if something must get rushed to production they may use to send in a Merge request with stricted turned off for the one file they are rushing.

@TheNickmaster21
Copy link

This feature would be great. We recently converted a medium sized project to strict mode and it was a huge endeavor. We are glad we made the change but there is no way we could do the same thing on our larger projects any time soon. We would love to have this as a mechanism to use strict mode on new development. This would also be great when slowly converting a project.

@netpoetica
Copy link

I have a use case that may help justify this. I am using gRPC to generate .ts and .d.ts, but then I am using tsc to compile everything into a dist. The generated files must have strict = false in tsconfig, but the files I write I want to to have strict = true in tsconfig. It would be ideal if there was a way to have a tsconfig.override.json inside of the dir that holds those protoc-generated files that tells the global compile process "hey, these files should use these other rules"

@kamkry
Copy link

kamkry commented May 26, 2021

While there are no built-in features like this in Typescript, we've created typescript-strict-plugin which allows you to turn on strict-mode in specific files or routes.
Hope it helps!

@Bernold1
Copy link

Is there any update on disabling strict mode for specific files?

@sgharms
Copy link

sgharms commented Jul 29, 2021

Here's another case: testing.

I write my tests in TypeScript 👍
They are are put in a directory for Jest to process 👍

If I add a jsdoc tweak to my test environment in a test file (say swapping 'node' test environment for 'jsdom'), the generated output is:

"use strict";
/**
 * @jest-environment jsdom
 */
test("derpson", function () {
    document.body.innerHTML =
        '<div>' +
            '  <span id="username" />' +
            '  <button id="button" />' +
            '</div>';
    console.log(document);
});

Without the magic comment being on line 0, the test breaks. Manually removing the line, everything works.

@bennycode
Copy link
Contributor

Would love to see this feature implemented as well. We have quite sizeable project and going "all strict" is not an option right now.

Same here! An ugly workaround would be enabling strict mode and adding the // @ts-expect-error comment everywhere where you cannot fix the compilation errors right away.

@bhanna1693
Copy link

I also agree that adding @ts-strict to the top of the file would have HUGE benefits for migrating. How is this coming along? Would love to see this implemented.

@netpoetica
Copy link

Would love to see this feature implemented as well. We have quite sizeable project and going "all strict" is not an option right now.

Same here! An ugly workaround would be enabling strict mode and adding the // @ts-expect-error comment everywhere where you cannot fix the compilation errors right away.

The problem is in use cases like mine, where those files are generated by the protoc compiler - I would need to re-add this ts-expect-error every single time, or author a script to do it - it would be quite painful. This solution works for manually-authored code but for generated code that is frequently overwritten, it would not suffice

@luddd3
Copy link

luddd3 commented Nov 19, 2021

I would like the inverse too. In one of our projects, most of the code-base follow "strict" rules, but some of the tests must use "any". It would be great to have a way to disable strict compilation in just those files.

@Lakston
Copy link

Lakston commented Feb 8, 2022

wouldn't adding // @ts-expect-error bring more problems by ignoring errors not related to strict mode ?

I can't see myself adding those annotation in a 100k LOC project on every single strict error, declaring a file as strict punctually would definitely be a better approach, allowing us to migrate our codebase on a per-file basis.

@Blackbaud-JasonBodnar
Copy link

Definitely need this to disable strict for tests. Sometimes you got break the rules to test something.

@acezard
Copy link

acezard commented Apr 23, 2022

As others have said this would be a very useful feature when converting projects from javascript to typescript. My workaround currently is to have a non-strict config versioned, and switch to a strict config when working on code. Still works but the suggested feature would be far better.

georgefst added a commit to hackworthltd/primer-app that referenced this issue May 17, 2022
The way we were previously implementing layout was messy, and contained arbitrary hardcoded values.

The file `useLayout.ts` came almost directly from the React Flow Pro example at https://reactflow.dev/docs/examples/layout/auto-layout/. But we had to add two `as never` annotation to get it accepted by TypeScript's strict mode. Note that the dodgy dynamic typing is confined to within the module, so the API is safe. Also note that we can't just turn off strict mode for a single module or definition: microsoft/TypeScript#28306.
@nelson6e65
Copy link

nelson6e65 commented May 18, 2022

As others have said this would be a very useful feature when converting projects from javascript to typescript. My workaround currently is to have a non-strict config versioned, and switch to a strict config when working on code. Still works but the suggested feature would be far better.

This workaround does not work when running a web-server in watch mode and coding. The tsconfig.json file is re-read when you change this setting and save a file. At least on my Angular 12/TypeScript 4.3 app.

@acezard
Copy link

acezard commented May 18, 2022

As others have said this would be a very useful feature when converting projects from javascript to typescript. My workaround currently is to have a non-strict config versioned, and switch to a strict config when working on code. Still works but the suggested feature would be far better.

This workaround does not work when running a web-server in watch mode and coding. The tsconfig.json file is re-read when you change this setting and save a file. At least on my Angular 12/TypeScript 4.3 app.

That is correct, I was working on a library where I didn't need any real-time compiling so I didn't encounter this problem. Still, let's say with a webpack-dev-server React app, I think I would develop in non-strict-mode then "strictify" everything before pushing the feature (at the refactoring step of development). Really not a great workflow I would admit.

@nelson6e65
Copy link

nelson6e65 commented May 18, 2022

My working workaround was using a tsconfig.app.json with strict:false for my Angular build/serve and then, adding /src/tsconfig.json which extends /tsconfig.app.json with only strict: true to be used by my Editor pluggin. So, I code on strict mode, but is served/built as if strict was false.

In my case I'm using Atom, and my Typescript pluggin search for tsconfig.json files and it uses for children *.ts files.

@nelson6e65
Copy link

If you need to strict check in your CLI, then you can use a tsconfig in each subdirectory as needed to use as your tsc --noEmit project. That's it! Now you can check strict partially to different subdirectories, helping with progressive migration to strict: true.

georgefst added a commit to hackworthltd/primer-app that referenced this issue May 24, 2022
The way we were previously implementing layout was messy, and contained arbitrary hardcoded values.

The file `useLayout.ts` came almost directly from the React Flow Pro example at https://reactflow.dev/docs/examples/layout/auto-layout/. But we had to add two `as never` annotation to get it accepted by TypeScript's strict mode. Note that the dodgy dynamic typing is confined to within the module, so the API is safe. Also note that we can't just turn off strict mode for a single module or definition: microsoft/TypeScript#28306.
dhess pushed a commit to hackworthltd/primer-app that referenced this issue May 25, 2022
The way we were previously implementing layout was messy, and contained arbitrary hardcoded values.

The file `useLayout.ts` came almost directly from the React Flow Pro example at https://reactflow.dev/docs/examples/layout/auto-layout/. But we had to add two `as never` annotation to get it accepted by TypeScript's strict mode. Note that the dodgy dynamic typing is confined to within the module, so the API is safe. Also note that we can't just turn off strict mode for a single module or definition: microsoft/TypeScript#28306.
dhess pushed a commit to hackworthltd/primer-app that referenced this issue May 25, 2022
The way we were previously implementing layout was messy, and contained arbitrary hardcoded values.

The file `useLayout.ts` came almost directly from the React Flow Pro example at https://reactflow.dev/docs/examples/layout/auto-layout/. But we had to add two `as never` annotation to get it accepted by TypeScript's strict mode. Note that the dodgy dynamic typing is confined to within the module, so the API is safe. Also note that we can't just turn off strict mode for a single module or definition: microsoft/TypeScript#28306.
dhess pushed a commit to hackworthltd/primer-app that referenced this issue May 26, 2022
The way we were previously implementing layout was messy, and contained arbitrary hardcoded values.

The file `useLayout.ts` came almost directly from the React Flow Pro example at https://reactflow.dev/docs/examples/layout/auto-layout/. But we had to add two `as never` annotation to get it accepted by TypeScript's strict mode. Note that the dodgy dynamic typing is confined to within the module, so the API is safe. Also note that we can't just turn off strict mode for a single module or definition: microsoft/TypeScript#28306.
dhess pushed a commit to hackworthltd/primer-app that referenced this issue May 26, 2022
The way we were previously implementing layout was messy, and contained arbitrary hardcoded values.

The file `useLayout.ts` came almost directly from the React Flow Pro example at https://reactflow.dev/docs/examples/layout/auto-layout/. But we had to add two `as never` annotation to get it accepted by TypeScript's strict mode. Note that the dodgy dynamic typing is confined to within the module, so the API is safe. Also note that we can't just turn off strict mode for a single module or definition: microsoft/TypeScript#28306.
georgefst added a commit to hackworthltd/primer-app that referenced this issue May 30, 2022
The way we were previously implementing layout was messy, and contained arbitrary hardcoded values.

The file `useLayout.ts` came almost directly from the React Flow Pro example at https://reactflow.dev/docs/examples/layout/auto-layout/. But we had to add two `as never` annotation to get it accepted by TypeScript's strict mode. Note that the dodgy dynamic typing is confined to within the module, so the API is safe. Also note that we can't just turn off strict mode for a single module or definition: microsoft/TypeScript#28306.
dhess pushed a commit to hackworthltd/primer-app that referenced this issue Jun 2, 2022
The way we were previously implementing layout was messy, and contained arbitrary hardcoded values.

The file `useLayout.ts` came almost directly from the React Flow Pro example at https://reactflow.dev/docs/examples/layout/auto-layout/. But we had to add two `as never` annotation to get it accepted by TypeScript's strict mode. Note that the dodgy dynamic typing is confined to within the module, so the API is safe. Also note that we can't just turn off strict mode for a single module or definition: microsoft/TypeScript#28306.
@jakebailey
Copy link
Member

See also #31035, which has a WIP PR: #49886

The PR's demo is exactly what this issue is asking for, I think. @weswigham

(Maybe this is a dupe? Or the other way around?)

@AmirSavand
Copy link

Oh, I need this so bad 😢.

@devanfarrell
Copy link

I haven't tried it but I saw this TS plug-in shared. https://github.com/allegro/typescript-strict-plugin

@kepek
Copy link

kepek commented Feb 8, 2023

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
In Discussion Not yet reached consensus Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests