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

Ability to control project scope #13895

Closed
johnnyreilly opened this issue Feb 6, 2017 · 5 comments
Closed

Ability to control project scope #13895

johnnyreilly opened this issue Feb 6, 2017 · 5 comments
Labels
Duplicate An existing issue was already created

Comments

@johnnyreilly
Copy link

This is a cross post of a behaviour that people have repeatedly requested be added to the webpack loaders for TypeScript (awesome-typescript-loader and ts-loader). To quote @s-panferov:

It looks like that people want to typecheck only files directly included by an entry point. My opinion is that the loader should output the same errors as in direct tsc call.

I decided to conduct a small survey about the preferred default behavior:

  1. Align with TypeScript and IDEs, check errors in files, specified by tsconfig.json and included from a resolution graph.
  2. Don't align with TypeScript and IDEs, check errors in files from a resolution graph only. Ignore files from tsconfig.json

s-panferov/awesome-typescript-loader#364

Are there any thoughts around supporting this behaviour in tsc itself? I can understand the desire but am very wary of introducing different behaviour in a loader to the actual compiler.

TypeStrong/ts-loader#267

@colinskow
Copy link

As it relates to the TypeScript compiler, I would like to be able to pass in a list of files to the command line AND use a tsconfig.json file for compiler options. Currently TypeScript throws an error if I try to do both. To overcome this I have to hardcode the files array in the config file, which is less than ideal for dynamic builds.

@mhegazy
Copy link
Contributor

mhegazy commented Feb 6, 2017

@colinskow this is tracked by #13575

@mhegazy
Copy link
Contributor

mhegazy commented Feb 6, 2017

@johnnyreilly, the compiler provide an API for transpilation (transpileModule) that reports no semantic errors. The intention here is you get your errors from the IDE for instance, and the transpilation process only transforms code. I would say this is a supported scenario, but i do not think it fits in tsc itself.

@johnnyreilly
Copy link
Author

@mhegazy thanks for responding. I think the idea here is to have an alternative to files which allows you to specify root or entry files. entryFiles if you will. The idea being that each entry denotes the root file of a distinct project context; all other files being pulled in the files it needs via import / require statements. Is that something that's ever been considered for tsc?

@mhegazy
Copy link
Contributor

mhegazy commented Feb 6, 2017

this is how files behave today anyways. you do not need to specify all the files in the files list, just the roots.

@mhegazy mhegazy added the Duplicate An existing issue was already created label Apr 27, 2017
@mhegazy mhegazy closed this as completed Apr 27, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

3 participants