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

Allow specifying exclude as a command line option #46005

Open
5 tasks done
remcohaszing opened this issue Sep 22, 2021 · 13 comments
Open
5 tasks done

Allow specifying exclude as a command line option #46005

remcohaszing opened this issue Sep 22, 2021 · 13 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@remcohaszing
Copy link

Suggestion

πŸ” Search Terms

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

  • exclude cli

βœ… Viability 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. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I would like to be able to specify the exclude option which exists in tsconfig.json as a command line option.

πŸ“ƒ Motivating Example

The tsc command line tool now supports the --exclude option. This option behaves the same as the "exclude": [] option in tsconfig.json.

πŸ’» Use Cases

In my experienct a TypeScript project currently typically needs 3 files (excluding actual code);

tsconfig.json for type checking, including tests etc.:

{
  "compilerOptions": {
    "declaration": true,
    "noEmit": true,
    // … Add more options as desired
  }
}

tsconfig.build.json for building a project, excluding tests etc. (this can be named however you like)

{
  "extends": "./tsconfig.json",
  // The real exclude patterns are project specific.
  "exclude": ["__tests__", "*.test.ts", "*.spec.js"],
  "compilerOptions": {
    // Actually do emit when building.
    "noEmit": false
  }
}

package.json including a prepack script for building the project:

{
  "scripts": {
    "prepack": "tsc -P tsconfig.build.json"
  }
}

Introducing the --exclude command line option removes the need for a custom build tsconfig. This unclutters the project root by removing the need for a specific tsconfig file only for building. So basically the following changes can be made:

tsconfig.build.json is deleted:

- {
-   "extends": "./tsconfig.json",
-   // The real exclude patterns are project specific.
-   "exclude": ["__tests__", "*.test.ts", "*.spec.js"],
-   "compilerOptions": {
-     // Actually do emit when building.
-     "noEmit": false
-   }
- }

package.json now uses the tsconfig.json file, but specifies the exclude pattern:

  {
   "scripts": {
-     "prepack": "tsc -P tsconfig.build.json"
+     "prepack": "tsc --noEmit false --exclude '__tests__' --exclude '*.test.ts' --exclude '*.spec.js'"
    }
  }
@sandersn sandersn added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Oct 6, 2021
@iofjuupasli
Copy link

I just ran into this issue. It was a little surprising that CLI has so many params but not the exclude. My case is the same: type checking of all ts files and building without tests.

@alexn-s
Copy link

alexn-s commented Nov 27, 2022

i would love an exclude option too. there are too many configs in a monorepo with all the toolings (prettier, tsconfig, ...). it would make things easier

@frank-weindel
Copy link

Absolutely agree with this. I was surprised there's no way to do this as it is. I'm also trying to keep to one tsconfig.json file and being allowed to specify an --exclude parameter would make that possible.

@iamrenejr
Copy link

Just hopping on, agreed that a --exclude flag in the CLI would be a good addition.

@travishaby
Copy link

Would like this too! I have a use case for using the tsconfig.json file for most of my tsc use, and then with a different configuration using the cli flags in a different part of the project.

@staplespeter
Copy link

I also want this. My client and server code is in a flatter directory structure than a complete "client" & "server" separation (as there is some shared model code), and I'm currently building server code with tsc and bundling client and React code with Parcel. tsconfig includes the entire source folder i.e. the client and server code.

Currently I cannot have the flexibility of node scripts:

  1. Building all the code
  2. Building only the server code

I either have to change the tsconfig each time or use a CLI exclude flag that can be added to another node script. Of course there are solutions but I prefer the flexibility of an exclude flag on the CLI

@AlJohri
Copy link

AlJohri commented Aug 17, 2023

I also have this exact same usecase. I would like to compile my code without tests so that I can quickly prototype something and then fix the tests at the end.

@remcohaszing
Copy link
Author

#54410 is somewhat related.

Offroaders123 added a commit to Offroaders123/NBTify that referenced this issue Feb 15, 2024
The more I look into this, the more complex it seems, and the less sure I am with both the way I have things now, as well as whether I like the other options instead.

I think I may just stick with TSC for compiling my package code in general, and if anything I can still do/try out the dual-build setup with ESM/CJS, but maybe just use TSC, since I can ensure that things are built consistently.

Should I provide synchronous APIs from NBTify? I think learning about how to work with async has really helped me progress, and I don't want to prevent someone else from learning that if I go with providing a sync option to my API. Or rather, if anything, that would only work in Node, because the Compression Streams API is only an asynchronous implementation. I'd have to use Node Zlib as a fallback to allow for a synchronous implementation, and it would be for Node only. I'm not sure I like the splintering of that either.

I think I have realized afterall, that I don't specifically want to use ESBuild for building my packages, since it's meant to bundle code, and I think I would only want to use that in a situation of building an ESM bundle for the browser. I may look into that as well though. Maybe I can use pkgbuild for that instead though? It kind of works a bit nicer for plain TS type generation support out of the box, as well as the configuation for things just plain working. Maybe I can look into making my own tool kind of like that, since it feels like all of the tools for this that I find, they all don't quite work exactly like how I want them to, unfortunately.

https://www.reddit.com/r/node/comments/14os7zv/the_esmcjs_situation/
https://github.com/wooorm/npm-esm-vs-cjs
https://stackoverflow.com/questions/46515764/how-can-i-use-async-await-at-the-top-level
https://stackoverflow.com/questions/71517624/because-i-cant-run-await-on-the-top-level-i-have-to-put-it-into-an-async-funct
https://commerce.nearform.com/blog/2021/node-esm-and-exports/
https://dev.to/a0viedo/nodejs-typescript-and-esm-it-doesnt-have-to-be-painful-438e
https://www.reddit.com/r/node/comments/14rg9ym/esm_not_gaining_traction_in_backend_node/
nodejs/node#49432
https://github.com/azu/tsconfig-to-dual-package
https://www.breakp.dev/blog/simple-library-package-setup-with-esbuild/
https://esbuild.github.io/api/#build
evanw/esbuild#263
evanw/esbuild#618
microsoft/TypeScript#46005

https://guitar.com/news/music-news/devin-townsend-shredding-dreams-steve-vai/
https://www.reddit.com/r/DevinTownsend/comments/17s332s/devin_and_the_vai_years/
https://www.reddit.com/r/DevinTownsend/comments/k9jot4/devin_townsend_i_was_unable_to_articulate_my/
https://www.kerrang.com/devin-townsend-i-was-unable-to-articulate-my-discontent-so-i-tended-to-act-up-i-even-took-a-sh-t-in-steve-vais-guitar-case
https://www.reddit.com/r/DevinTownsend/comments/6tia0r/is_vai_comparing_devin_to_zappa/
Offroaders123 added a commit to Offroaders123/NBTify that referenced this issue Feb 21, 2024
The more I look into this, the more complex it seems, and the less sure I am with both the way I have things now, as well as whether I like the other options instead.

I think I may just stick with TSC for compiling my package code in general, and if anything I can still do/try out the dual-build setup with ESM/CJS, but maybe just use TSC, since I can ensure that things are built consistently.

Should I provide synchronous APIs from NBTify? I think learning about how to work with async has really helped me progress, and I don't want to prevent someone else from learning that if I go with providing a sync option to my API. Or rather, if anything, that would only work in Node, because the Compression Streams API is only an asynchronous implementation. I'd have to use Node Zlib as a fallback to allow for a synchronous implementation, and it would be for Node only. I'm not sure I like the splintering of that either.

I think I have realized afterall, that I don't specifically want to use ESBuild for building my packages, since it's meant to bundle code, and I think I would only want to use that in a situation of building an ESM bundle for the browser. I may look into that as well though. Maybe I can use pkgbuild for that instead though? It kind of works a bit nicer for plain TS type generation support out of the box, as well as the configuation for things just plain working. Maybe I can look into making my own tool kind of like that, since it feels like all of the tools for this that I find, they all don't quite work exactly like how I want them to, unfortunately.

https://www.reddit.com/r/node/comments/14os7zv/the_esmcjs_situation/
https://github.com/wooorm/npm-esm-vs-cjs
https://stackoverflow.com/questions/46515764/how-can-i-use-async-await-at-the-top-level
https://stackoverflow.com/questions/71517624/because-i-cant-run-await-on-the-top-level-i-have-to-put-it-into-an-async-funct
https://commerce.nearform.com/blog/2021/node-esm-and-exports/
https://dev.to/a0viedo/nodejs-typescript-and-esm-it-doesnt-have-to-be-painful-438e
https://www.reddit.com/r/node/comments/14rg9ym/esm_not_gaining_traction_in_backend_node/
nodejs/node#49432
https://github.com/azu/tsconfig-to-dual-package
https://www.breakp.dev/blog/simple-library-package-setup-with-esbuild/
https://esbuild.github.io/api/#build
evanw/esbuild#263
evanw/esbuild#618
microsoft/TypeScript#46005

https://guitar.com/news/music-news/devin-townsend-shredding-dreams-steve-vai/
https://www.reddit.com/r/DevinTownsend/comments/17s332s/devin_and_the_vai_years/
https://www.reddit.com/r/DevinTownsend/comments/k9jot4/devin_townsend_i_was_unable_to_articulate_my/
https://www.kerrang.com/devin-townsend-i-was-unable-to-articulate-my-discontent-so-i-tended-to-act-up-i-even-took-a-sh-t-in-steve-vais-guitar-case
https://www.reddit.com/r/DevinTownsend/comments/6tia0r/is_vai_comparing_devin_to_zappa/
@maelp
Copy link

maelp commented Mar 12, 2024

is there an option to do this?

@MatthewSkingley
Copy link

It seems natural to expect parity between the command line flags of the tsc cli and tsconfig.json. For instance, webpack supports a cli where "Any parameters sent to the CLI will map to a corresponding parameter in the configuration file."

My use case is that I'd like to download a github repo by tag with the degit tool, make no changes to the repository (Not create an additional tsconfig.declaration.ts), and generate declaration files for the repo simply by executing.

tsc --declaration --emitDeclarationOnly --declarationDir ./myDeclarations --exclude "src/**/*.spec.ts"

I want this to be a helper npm script in my project root as "postinstall":, where I would rather not need to invoke touch to create the custom tsconfig as it would break platform compatibility.

@GitMurf
Copy link

GitMurf commented Jun 3, 2024

Have we heard any comment from anyone on the TypeScript team? This has been open for almost 3 years with many folks having similar needs and no response? I would greatly appreciate it if the TypeScript team could at least acknowledge the "issue", maybe provide a recommended "workaround" and if the TypeScript team down not feel this is a good thing to add to the CLI then it would be wonderful to have an explanation. Thanks!

@thardy
Copy link

thardy commented Jun 20, 2024

Why has this not been done? This is a no-brainer.

@cenkakay
Copy link

3 years????

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests