tsc-files: Current version incorrectly analyzes @types/node

For the purposes of lint-staged I updated my entry to include my .d.ts files

My package.json went from

{
    "lint-staged": {
        "**/*.{ts,tsx}": [
            "tsc-files --noEmit"
        ]
    }
}

To:

{
    "lint-staged": {
        "**/*.{ts,tsx}": [
            "tsc-files --noEmit src/defines.d.ts src/path/to/other.d.ts"
        ]
    }
}

This worked for my commits as the lint staged files will get added on after. Maybe an ‘–global-files’ option that supports globing could be added to tsc-files to add be able to use globs in the list as lint staged does not expand them.

@benwainwrightcinch Now I’m wondering if an --include option should be added so you’d run tsc-files some-file.ts --include "**/*.d.ts". Perhaps even have **/*.d.ts as the default value? I’d like to know what people following this issue think.

{
    "lint-staged": {
        "**/*.{ts,tsx}": [
            "tsc-files --noEmit src/defines.d.ts src/path/to/other.d.ts"
        ]
    }
}

this seems like the best solution to me. You really only need one file so long as imports whatever other globals you want.

For the purposes of lint-staged I updated my entry to include my .d.ts files

My package.json went from

{
    "lint-staged": {
        "**/*.{ts,tsx}": [
            "tsc-files --noEmit"
        ]
    }
}

To:

{
    "lint-staged": {
        "**/*.{ts,tsx}": [
            "tsc-files --noEmit src/defines.d.ts src/path/to/other.d.ts"
        ]
    }
}

This worked for my commits as the lint staged files will get added on after. Maybe an ‘–global-files’ option that supports globing could be added to tsc-files to add be able to use globs in the list as lint staged does not expand them.

Props to this comment I fixed the issue on NextJS

"tsc-files --noEmit next-env.d.ts"

I discovered today that our large monorepo project that makes use of tsc-files to compile individual files on commit hooks suffered from the problem described in https://github.com/gustavopch/tsc-files/issues/5.

This can be overcome by creating a base tsconfig containing all your compiler settings, and a different tsconfig for specific use with ts-files, so:

// tsconfig.base.json
{
   // All your typescript settings, WITHOUT your "include", "exclude" or "files" properties
}

// tsconfig.ts-files.json
{
   "extends": "./tsconfig.base.json",
   "include": ["**/*.d.ts"]
}

// tsconfig.json
{
   "extends": "./tsconfig.base.json",
   "include": ["**/*.ts"] // the normal 'include' array for your project
}

This approach works well, and means you are still controlling the compilation source set using the config file rather than the command line as with the above solution. If I were to update the project to the latest version of ts-files, it would break us because you are overwriting the includes property.

In my view, you probably should revert https://github.com/gustavopch/tsc-files/pull/18, as its an unnecessary solution that can be solved by configuring the compiler properly, and makes your tool harder to understand by those that expect the ‘include’ property to work as intended by the TypeScript team.

Is it possible to use a glob in includes to include all *.d.ts files, rather than having it be entirely blank? This is a breaking issue for me so I also had to rollback.

Also, I noticed that 1.1.3 has broken your automated testing, so it really shouldn’t have been rolled into your main branch – it’s just bad code practice.

Note for anyone trying to import images into a TypeScript/React project: I had to create separate declaration files for each image type. Putting them into the same file didn’t work.

png.d.ts:

declare module "*.png" {
  const content: string;
  export default content;
}

svg.d.ts:

declare module "*.svg" {
  const content: string;
  export default content;
}

"lint-staged": {
    "**/*.{ts,tsx}": "sh -c 'tsc-files --noEmit $(find ./src -name *.d.ts ! -path \"./src/.*/*\") $0 $@'"
},

i’m using this cmd to specify all d.ts

I’d like to know what people following this issue think.

@gustavopch I’d suggest a warning which offers a recommended solution for projects which define “includes” in tsconfig. As we discussed in #5 it defeats the purpose of the project to include all files.

@gustavopch I don’t mind if you need to revert.

Honestly I know very little about TypeScript and just hit this rep after discovering terrible performance in our linting (>30s for a single file). I’m hoping to come back and think about this in some more depth soon 😃

While #18 solved one of my issues, I’ll have to rollback to a previous version.

I wondered if we could use the compilerOptions.typeRoots on-top of #18? This worked for my two use-cases, but I noted some caveats…idea in a PR: https://github.com/gustavopch/tsc-files/pull/22

_Edit: I also created a minimal example for the above PR: https://github.com/kylorhall/tsc-files-types-example_

I think this empty include introduces the issue where custom types are not able to include. I have below running correctly in v1.1.2, but not in v1.1.3 % yarn tsc-files --noEmit src/App.tsx

src/App.tsx

function App() {
  return (
    <>
          Learn React {`test ${window.test()}`}
    </>
  );
}

export default App;

src/types/window.d.ts

export {};
declare global {
  interface Window {
    test: () => string;
  }
}