Discovering .ts files under node_modules resulting in them being compiled

[billti]

I uncovered this general issue while testing loading JavaScript files from node_modules, but realized (and confirmed) this applies to TypeScript files also.

Basically, when we search the node_modules folder, we look for all supported extensions and add them to the compilation. Currently this means that if we find a TypeScript file in a Node module (e.g. someone published their package including the source), then we compile this also.

For example, if module sausages was published as follows (with the original source besides the compiler files):

 - node_modules
 |- sausages
   |- package.json
   |- core.ts
   |- core.js

Then we get the benefit of loading the .ts and getting the types from this. However on compiling an app which uses the sausages/core module, with outDir: "out", I get the resulting output (notice how core.js from the sausages package has been compiled into a node_modules folder in my outDir).

I already added a flag to denote if a file was found by searching Node modules in this pull request. I can refactor this to eliminate this issue if that seems reasonable.

[weswigham]

I think TS has had this issue since #4911 - there's some discussion in the PR on the subject. I also had changes in #4913 which marked files which were included via a node_modules directory (so they could be scoped appropriately).

[billti]

I've added a potential fix for this into #6928, as both depend on knowing if code was discovered downstream of a search under node_modules.

[igabesz]

I think this is a kinda serious issue in node based development. Currently I see the following options when using tsc in Node-based apps:

1. Include each *.ts files in your tsconfig. Better have a plugin for this (e.g. atom-typescript) because you don't wanna do this manually. The tsconfig will be updated whenever a TS file is added/deleted/replaced, which is also inconvenient.
2. Use exclude in tsconfig and exclude node_modules. If you have a TS-based module (e.g. you wrote one) then the included definitions won't be found (e.g. "typings": "lib/index.d.ts" in package.json) and neither can you use typings because it says you already have the typings under node_modules. Thank you.
3. Use exclude but NOT exclude node_modules: every *.ts file will be compiled under node_modules resulting in lots of warnings and errors because of using different linter options, not having all the typings used in those modules, etc.

Or leave tsc out of the business and let the IDE make the compilations (again, with atom-typescript, using filesGlob property which is the most convenient thing so far) and put all JS files into source control as well. It works conveniently on the developer side, but I don't think I have to enumerate the cons...

I know, there will be much rejoicing when global includes arrive #1927 -- but what until then??

> tsc -v
Version 1.8.9

[jpsfs]

I'm also facing this issue. My use case is the following:

| -- Solution
      | -- projectA
      | -- projectB
            | -- node_modules
                  | -- projectA (syslink to the folder above)

When compiling projectB, without the --outFile flag all works exactly as it should, unfortunately when using --outDir in conjunction with --module it bundles more than it should, bringing the code from projectA over to the bundle of projectB. Not what we were looking for.

Anyone knows a workaround for this?

[mhegazy]

in projectA's package.json, define `"typings": "<main .d.ts file of projectA>"``. this will force the compiler to load the .d.ts instead of loading the .ts files.

[jpsfs]

Thanks @mhegazy!

Although in this case we don't have a "main" .d.ts file.
In projectB we have several direct imports:

import "projectA/components/grid";
import "projectA/components/combobox";
...

And I rather not maintain a separate file that exports all of the components. We want to avoid giving the developers the possibility of doing something like

import * as PA from "projectA/components"

because each component may load additional 3rd party libraries and importing all will also load all of the dependencies, when most of the times they are not needed.

Do you have any other suggestion for this case?

Regards,

[mhegazy]

consider not including the .ts files in your package when you publish it.

[jpsfs]

@mhegazy we face this during development.

To give you a bit more context: the same team is responsible for the development and maintenance of more than a dozen typescript projects. To ease the development, the packages are linked, through npm link, in the development environment.

So, removing the .ts files when we publish them is fine (we are already doing that) but it's not an option during development.

The current setup works but the compiler performance is a serious handicap. On the top layer packages (those which depend on 8 or 9 other typescript packages) it seems the compiler goes through all the files and compiles them.

I already had the chance to talk with @jmatthiesen about our problems with VS and VSCode. I'm available to show you guys our environment if you are interested.

Best,

[mhegazy]

i see. thanks for the clarification. Do not think there are other workarounds other than fixing this issue.

[ps2goat]

+1 - I only see this when bundling my files using the outFile parameter. It doesn't pull in everything, though. Angular 2 (beta.08) is not being compiled and bundled with our app code, but some other third-party packages are. E.g., ng2-bootstrap (1.0.1-beta.2).

node_modules is already excluded in tsconfig.