Tries to compile sources that are not supposed to be loaded

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

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.

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.

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... @_@

@blakeembrey

@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

@timocov

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 🌷

@johnnyreilly

@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.

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

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...

@johnnyreilly

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

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
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.

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!

Related to #54

Make both app and tests compile now. For tests, Node 6.9 needed

Are there recommendation how it could be worked around?

@whitecolor we ought to use awesome-webpack-loader for tests sub-project and ts-loader for the base project, which is inconvenient

What about ignoring the files and include parts of tsconfig.json and only compile the files known to webpack? This would simplify everything.

This is what rollup-plugin-typescript2 does, it only checks for the compilerOptions part of tsconfig.json (see #646).

@tkrotoff

We'd be open to a pull request if you fancied implementing this @tkrotoff.

@johnnyreilly

@johnnyreilly first we need to be sure there no need for files and include parts from tsconfig.json. Is there any counter-example? And also it will break compatibility.

@tkrotoff

@tkrotoff - if it goes in it would be behind a flag. ts-loader aims to be a drop in replacement for tsc as much as is practical. Since this would deviate from that I'd want this to be "opt-in" behaviour; not default.

To your question: I believe files and include are both optional.

To your question: I believe files and include are both optional.

There is a misunderstanding. Of course files and include are optional in tsconfig, not talking about that.

What I suggest is to totally ignore them inside ts-loader: ts-loader would only compile what webpack provides, nothing more.

Ok I see. As long as you're ok with this being opt-in rather than default behaviour then I say start implementing in a PR and use that as a basis for conversation. Don't worry about failing tests or anything- just hack about, raise a PR and talk to me. Let's see what happens! 😄

@johnnyreilly

@johnnyreilly

start implementing [...] use that as a basis for conversation

I prefer you to be sure that the idea is good and it's the proper way to handle things. I don't want to spend hours on a PR that ends up with "sorry, the idea is wrong, here is a valid use case where we need files/include from tsconfig.json".

For me it's clear:

files and include from tsconfig.json => tsc
webpack entry (and nothing else except compilerOptions) => ts-loader (the way rollup-plugin-typescript2 works)

In my opinion it should have been this way from the start. Currently ts-loader mix tsconfig.json files/include and webpack entries (+ other things hence the current issue) and it's a mess.

Ping @s-panferov any opinion on this?

@s-panferov

On the face of it seems reasonable.

I'd suggest start attempting it - it might be the case that doing so reveals "dragons". Or not. Purely from my own perspective I find it easier to think about code during implementation; hence my suggestion.

As always, @s-panferov views could be helpful. Just to be clear though, I would plan to put this behaviour behind a feature flag (loader option) at least initially. If it's clear that this can be inferred from the tsconfig.json then great. But I'm not counting on it.

@maier49

This should be resolved by @maier49's PR: #671

Hope to ship this with ts-loader 3.1.0

I am still seeing this issue in ts-loader 3.2.0. It makes ts-loader and webpack literally unusable for us.

Webpack loaders are supposed to be called to handle the files you're building with webpack - not to spend minutes blindly processing every file in your repository and then blowing up because of unrelated issues.

Edit: For anyone else reading, you can work around this bug by specifying the option onlyCompileBundledFiles like so

use: [{loader: 'ts-loader', options: {onlyCompileBundledFiles: true}}]

I still find it astonishing that ts-loader is broken by default, but at least there's a workaround.

ts-loader intentionally mirrors the behaviour of tsc as closely as possible.

If tsc thinks your code is probably broken then ts-loader should say so too. We do this so there's not a disconnect between the editor / IDE experience and your build.

The onlyCompileBundledFiles is one of a number of flags that allows you to deviate behaviour from tsc and align closer with typical webpack behaviour.

ts-loader is broken by default

It's not, it's just not the behaviour you expected.

I am still seeing this issue in ts-loader 3.2.0. It makes ts-loader and webpack literally unusable for us.

To be clear: is it usable with the onlyCompileBundledFiles flag? Or not?

I was under the impression that ts-loader is intended to be used with webpack. Why not follow the standard webpack behavior in that case?

To be clear: is it usable with the onlyCompileBundledFiles flag? Or not?

Yes. The issue is that there were a large number of other files in the repository which shouldn't be checked but which ts-loader checks by default. Setting the flag fixed this.

P.S. Sorry for the overly harsh language earlier. I understand that it is working as intended, I just can't understand why it is intended to behave like that, and I don't think the default behavior makes sense, which makes it a bug from my perspective.

I was under the impression that ts-loader is intended to be used with webpack. Why not follow the standard webpack behavior in that case?

It is intended to be used with webpack. However we want the typical compiler behaviour to tie up with ts-loader as much as possible.

Partly to give a good editor / IDE experience. Partly because webpack is not the only game in town. People may move to webpack and away from webpack as a build choice. There can be good reasons to do either. Ideally that should be a frictionless experience. We don't want people to have to use webpack / ts-loader - it should be a choice. The minute we have default behaviour that deviates from tsc then we've started down that unfortunate road.

It might not be the choice you prefer but it's not something that's likely to change, for the reasons given. That said, I'm glad onlyCompileBundledFiles gives you what you need. That's fantastic!

It's possible (probable!) that our docs could be clearer around this. If you wanted to submit a docs PR to improve things I'd happily take a look. All the best : 🌻

Hello,

Yes this issue caught me off guard as well
And for the record awesome-typescript-loader is also doing the same thing but each have a different workaround

onlyCompileBundledFiles fixes the issue to ts-loader
on the other hand fixing the issue for awesome-typescript-loader seems to be adding a "files": [],in tsconfig.json but ts-loader and TSC complains that TS18002: The 'files' list in config file 'tsconfig.json' is empty.

{
    "compilerOptions": {
        "sourceMap": true,
        "noImplicitAny": true,
        "module": "esnext",
        "target": "esnext",
        "allowJs": false,
        "checkJs": false
    },
    "files": [],
    "exclude": [
        "node_modules",
        "dist",
    ]
}

Navigation Menu

Repository navigation

Tries to compile sources that are not supposed to be loaded #267

14 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tries to compile sources that are not supposed to be loaded #267

Description

Activity

blakeembrey commented on Aug 20, 2016

wclr commented on Aug 21, 2016

Vloz commented on Sep 17, 2016

timocov commented on Oct 12, 2016

johnnyreilly commented on Oct 12, 2016

ezhukovskiy commented on Oct 12, 2016

johnnyreilly commented on Oct 16, 2016

johnnyreilly commented on Oct 17, 2016

ezhukovskiy commented on Oct 20, 2016

johnnyreilly commented on Oct 25, 2016

johnnyreilly commented on Oct 26, 2016

wclr commented on Nov 28, 2016

ezhukovskiy commented on Nov 29, 2016

14 remaining items

tkrotoff commented on Sep 28, 2017

johnnyreilly commented on Sep 28, 2017

tkrotoff commented on Sep 28, 2017

johnnyreilly commented on Sep 28, 2017

tkrotoff commented on Sep 28, 2017

johnnyreilly commented on Sep 29, 2017

tkrotoff commented on Sep 30, 2017

johnnyreilly commented on Sep 30, 2017

johnnyreilly commented on Oct 26, 2017

Storyyeller commented on Dec 20, 2017

johnnyreilly commented on Dec 21, 2017

Storyyeller commented on Dec 21, 2017

johnnyreilly commented on Dec 21, 2017

ericnoguchi commented on Dec 31, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions