awesome-typescript-loader
awesome-typescript-loader copied to clipboard
s-panferov
Ability to control a project scope
I've received several similar issues about how to control project scope.
#359 #351 #348 #330
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:
-
Align with TypeScript and IDEs, check errors in files, specified by
tsconfig.jsonand included from a resolution graph. -
Don't align with TypeScript and IDEs, check errors in files from a resolution graph only. Ignore files from
tsconfig.json
Please answer in comments and elaborate your position.
CC @johnnyreilly
I think aligning with tsc makes the most sense as it reduces the "distance" between tsc and working with webpack. Ideally I'd like any TypeScript loader to be a minimal difference from working with the compiler straight - focused on bundling alone pretty much. Also the loader can be simpler as a result. That said I understand the alternative point of view and understand to a certain extent. But if it becomes a feature of a loader then you're starting down the road of creating a codebase that has a tight coupling to that loader behaviour. Which is bad if you ever want to move away from webpack.
Oh and additionally: for tooling reasons. I want to see the same output in VSCode / atom / brackets etc as I do from webpack. Otherwise I have to code with red squigglies and learn to ignore them - which is a nasty development experience.
The default should remain unchanged tsconfig.json (otherwise we risk breaking lots of builds.)
However I would also like loader options to support the following scenarios:'
- Load entry files only
- Load entry files, plus a custom list of additional files
Since I haven't figured out how to pass a virtual tsconfig.json to ATL I wrote a plugin that writes a custom config file for each build. But this is not ideal. I would like to pass in options without having to write a config file.
I propose the following two configuration options:
{
entriesOnly: true, // default false
additionalFiles: ['src/app/app.module.ts'] // only parsed when entriesOnly is true
}
These options simply generate a files array which is passed in with the tsconfig object to the compiler.
Some background on my use case:
I have an Electron project with separate builds for main and renderer processes, as well as e2e tests and unit tests in TypeScript. They have conflicting Typings, so I get errors unless I am able to restrict type checking to the resolution graph.
With Angular 2, lazy loaded modules don't show up in the dependency graph, so it is necessary to specify those files in addition to entry points.
Since my project has lots of .ts files which aren't part of the main build, restricting the type checking makes builds run quite a bit faster.
Has anyone raised an issue with the TypeScript team itself to implement this behaviour in tsc? If they did implement then I would naturally be in favour of supporting this. Likewise if there's a reason they've chosen not to that could well be relevant. Is anyone aware of any discussion on the topic?
@johnnyreilly TypeScript has implemented this behavior, but you have to specifically specify the entry files in the files array in your tsconfig.json. What I am asking for is the ability to pass this to the loader as an object in memory rather than writing a config file to disk.
@colinskow are you sure that's correct? My understanding was that if you are going to specify files then you're required to specify everything in project scope. So import or require statements do not contribute to project scope. Also, each entry represents an isolated scope and the tsconfig.json files does not indicate isolated scopes at all.
@johnnyreilly you can test that out for yourself. Specify one entry file in the files array in your tsconfig.json and it will compile everything in the dependency tree, but will ignore all files outside the dependency tree.
Checkout my personal setup here: https://github.com/colinskow/angular-electron-dream-starter/blob/master/config/webpack.common.js#L44
Ah - well that's news; thanks for sharing @colinskow,
However, the problem is that it doesn't allow for multiple distinct entry points; i.e 2 different clashing project scopes driven by 2 entries in the same files array.
@johnnyreilly again, you can test for yourself but in my experience it does allow for distinct entry points. TypeScript should parse all files in the files array along with their entire dependency tree.
Somewhere somewhere I have a setup that demonstrates an issue with this. Alas I can't remember where... Perhaps my fears were unfounded - sounds like it
If I simply specify an empty files[] in my tsconfig.json, then tsc seems to ignore files that are not reachable from any of my entries.
@oocx that could work if it weren't for lazy loaded modules. In order to get lazy loaded modules to work they need to be added manually to the resolution graph.
I currently use grunt-ts and can pass in the files I want, this is useful since I have multiple apps and partners in the same project. With grunt I can specify the project and app to build and the associated files, right now this is unusable since I just get errors about duplicate identifiers.
It also makes a slow transition from grunt-ts impossible since I want to continue to run some files through that while I am making the transition.
I personally would like to state my support for option 2, even if that's as a non-default option. I think if you're using a loader with Webpack then you expect the loader to behave the "Webpack way" above all else. This is the only loader I've come across (used a few dozen total) thus far that doesn't determine which files to work on via the resolution graph.
I'm the author of #348, I also would like this repo aligned with tsc.
I'm using at-loader to build some AWS Lambda functions. apex-typescript-example
Would be nice to have entriesOnly: true option to avoid checking the whole project when I build one function.
I'm using at-loader on a project where we strip some function and files when building.
All the strip logic is inside webpack, and we really appreciate that when a file does not import a stripped depencendies, webpack does not load the associated files.
But at-loader always check these files, and we have lot of errors. Our strip configuration is dynamic, so we cannot really write it inside tsconfig.json
2 would be nicer. Currently in create-react-app-ts if your tests error on the initial compile, it throws an error, but it only reloads the files referenced by the entry point, which means you need to restart the compoile step.
+1 waiting for that feature for a long time... agree that it should align with webpack, as webpack is oriented from the perspective of the entry point. any workarounds though?
i found that ts-loader offers an options named onlyCompileBundledFiles , could we follow this?
excludeFiles, entryFiles and any others just can't be so simple and understandable
