Tries to compile sources that are not supposed to be loaded

[wclr]

Webpack 2 and TS2 beta
ts-loader tries to compile even source that should not be loaded by webpack. Is it expected behaviour?

[blakeembrey]

Can you give more information? I can't tell you without seeing an example, but most like it's not compiling it - it's using it for type information and that would be expected.

[wclr]

I serve files mostly in /client directory (by ts-loader), and I have ts file say server-somthing.ts in /server (that is loaded using ts-node) - this file is not shared with client part.

And say there is a mistake in server-somthing.ts.

But when webpack lanunches it error with compile error in server-somthing.ts. To get rid of it I have to limit files in tsconfig and if I use awesome-typescript-loader instead of ts-loader (just replace for it in webpack.confg) it works ok - doesn't try to compile server-somthing.ts.

[Vloz]

Same things for me:
ts-loader is giving error from file not used in the entry, but are part of the file tree.
I have 5 different ts entry path in the same filetree, and it looks like they are parsing each-other's files... Wonder if it doesnt overslow the build speed... @_@

[timocov]

@blakeembrey Hi, guys! This issue prevents us from using ts-loader. We've made a simple example so you can reproduce it.
This example contains tests folder with additional dependencies in package.json which are not to be installed to build the base project.
just unpack it, and run

npm install
./node_modules/.bin/webpack

You'll get an error in tests/src/test.ts which is not required to build the base project:
(1,25): error TS2307: Cannot find module 'jquery'.

Example project: ts-loader-fail.zip

[johnnyreilly]

Hi @timocov,

Thanks for the repro - that's very helpful and we're always grateful when someone can provide a clear example of something not working as they expect.

We're open to a receiving a PR that will resolve this 🌷

[ezhukovskiy]

@johnnyreilly Hi, this issue is solved in awesome-typescript-loader.
The problem is that after-compile in ts-loader looks for errors in all files from tsconfig.json.
Look at how it is done in awesome-typescript-loader:
https://github.com/s-panferov/awesome-typescript-loader/blob/master/src/instance.ts#L396
It seems that they gather all files the loader was called for and checks them in after-compile.
I believe that you will be able to understand more from their code knowing how it is done in ts-loader.

[johnnyreilly]

Thanks for the clarification @eugenezee - very helpful. PRs welcome!

[johnnyreilly]

Hi @EugeneZee,

I took a quick look at the awesome-typescript-loader approach and it wasn't obvious to me where they gather just the files the loader was called for. Could you clarify that for me please? I'm interested in using this approach; I just need to understand exactly how it works... This looks like it might be what you're talking about?

https://github.com/s-panferov/awesome-typescript-loader/blob/master/src/instance.ts#L443

But without diving deep into the source of atl it's not clear to me where the information about which files the loader was called for comes from...

[ezhukovskiy]

@johnnyreilly Hi,
As soon as I understand it stores files when it is called to compile it:

1. In a "global" array that will be used to check errors:
   https://github.com/s-panferov/awesome-typescript-loader/blob/master/src/index.ts#L61
2. In an instance array that will be used to create phantomImports:
   https://github.com/s-panferov/awesome-typescript-loader/blob/master/src/index.ts#L58

On after-compile it checks list [1] for errors and gathers all the files in the project like ts-loader, but then it checks where the compiled files list [2] contains them or not. If a file is not in the list it puts it in phantomImports:

https://github.com/s-panferov/awesome-typescript-loader/blob/master/src/instance.ts#L443

He uses phantomImports to find appropriate declaration (d.ts) files. He puts them in compilation.assets and compilation.fileDependencies.

[johnnyreilly]

Thanks for the write up @EugeneZee - very helpful. This is on my radar but I'm not sure when I'll get to it; in the meantime PRs are always welcome!

[johnnyreilly]

Related to #54

[wclr]

Are there recommendation how it could be worked around?