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

Exclude option is not respected in tsc #7432

Closed
louy opened this issue Mar 8, 2016 · 17 comments
Closed

Exclude option is not respected in tsc #7432

louy opened this issue Mar 8, 2016 · 17 comments
Labels
By Design Deprecated - use "Working as Intended" or "Design Limitation" instead

Comments

@louy
Copy link

louy commented Mar 8, 2016

TypeScript Version:
1.8.7
1.8.0
1.7.5

Code

{
  "exclude": ["node_modules"]
}

Expected behavior:
Shouldn't build any .ts files in node_modules.

Actual behavior:
Builds files in node_modules. If target: es6 I get lots of SyntaxErrors in node.

@louy louy changed the title Exclude option is not respected in build step Exclude option is not respected in tsc Mar 8, 2016
@louy
Copy link
Author

louy commented Mar 8, 2016

The same issue happens when using the "files" option actually. Isn't there a way to void this?

@DanielRosenwasser
Copy link
Member

What do your source files and dependencies look like?

@DanielRosenwasser DanielRosenwasser added the Needs More Info The issue still hasn't been fully clarified label Mar 8, 2016
@mhegazy
Copy link
Contributor

mhegazy commented Mar 8, 2016

One thing to note, exclude is about the compiler automatically loading all files from your folder when you run tsc with no file list. This does not impact in any shape of form how import statements are resolved. if the compiler sees import * from "mod", and --moduleResolution node then it will try to find mod in node_modules and if it found it it will include it.

if this is not what you want, use --moduleResolution classic.

@louy
Copy link
Author

louy commented Mar 9, 2016

Here's the minimal setup:

a.ts

import './b';

b.ts

export = 1;

tsconfig.json

{
  "exclude": ["b.ts"]
}

and then...

$ ls
a.ts b.ts tsconfig.json
$ tsc -p .

$ ls
a.ts a.js b.ts **b.js** tsconfig.json

I would expect tsc not to compile b.ts.

@mhegazy
Copy link
Contributor

mhegazy commented Mar 9, 2016

As I mentioned in #7432 (comment), and as mentioned in https://github.com/Microsoft/TypeScript/wiki/tsconfig.json:

Any files that are referenced by those specified in the "files" property are also included. Similarly, if a file B.ts is referenced by another file A.ts, then B.ts cannot be excluded unless the referencing file A.ts is also specified in the "exclude" list.

exclude is just a convenience. it saves you from writing the names of all your files on the command line tsc a.ts b.ts c.ts ....

Now you have an import './b', this might have a side effect, i.e. a module augmentation (see https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#augmenting-globalmodule-scope-from-modules) and that needs to be visible in your system. moreover, if you use any imported values e.g. import {a} from 'b', the compiler needs to know what a means to be able to give you any meanigful type checking.

@mhegazy mhegazy closed this as completed Mar 9, 2016
@mhegazy mhegazy added By Design Deprecated - use "Working as Intended" or "Design Limitation" instead and removed Needs More Info The issue still hasn't been fully clarified labels Mar 9, 2016
@louy
Copy link
Author

louy commented Mar 9, 2016

I see your point, and I understand the reason. Still I believe something should be done.

So this becomes really inconvenient with node_modules written in typescript. I don't want typescript touching my node_modules folder. Generating .d.ts files doesn't help either. Isn't there a way to avoid this? Or should I not publish source files to npm?

@louy
Copy link
Author

louy commented Mar 9, 2016

At least a way of saying .d.ts files should have higher priority over .ts files

@mhegazy
Copy link
Contributor

mhegazy commented Mar 9, 2016

if you do not want the compiler to resolve any files for you, use --noResolve. but that means that all your modules will not be resolved.

I do not think this is the real problem. the real problem is really why you need to exclude some module typings. what is the offending file that you are trying to exclude.

@louy
Copy link
Author

louy commented Mar 9, 2016

Well, I'm using TS + babel to be able to use async/await in node. So in my tsconfig file I have target: es6 and I cannot change that.
I use babel-register and a small set of transforms with node 5.7. by default babel-register doesn't apply transforms to anything inside node_modules because it will have a huge impact on performance.

I have a couple of npm modules I have written myself in Typescript (one of them is called rabbitr). They are compiled to ES5 and should work fine in node. The problem is when I run tsc -p . it recompiles those modules to ES6, and they suddenly stop working in node unless I whitelist them in babel. I don't want to have to whitelist every single npm module written in typescript. That's the problem.

@mhegazy
Copy link
Contributor

mhegazy commented Mar 9, 2016

that is the problem then. the compiler should not compiler your references. this is tracked by #6964.

consider using a "typings" property in your package.json for your module (rabbitr). this way you can point it to a .d.ts and that will always be picked. see https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages

@3du4
Copy link

3du4 commented Sep 29, 2016

Reading this ticket, then it is good to assume to do not exclude the files under node_modules?

@mhegazy
Copy link
Contributor

mhegazy commented Sep 29, 2016

I do not understand the question

@3du4
Copy link

3du4 commented Sep 30, 2016

@mhegazy thank you for having a look to my question.
Looking at this comment #7432 (comment), it mentions that excluding node_modules it might have some impact on the project.

The reason of my question is because I have an Angular 2 project using 2.0.1 and when running 'tsc' it runs the transpiling process to all my files�, .ts and d.ts under node_modules. Because of this, it throws some errors coming from some libraries (not Angular). I assume because these ones might be using different versions of TypeScript? I wanted to use the exclude option and that brought me here.

What would be the best way to solve this issue? Any help would be greatly appreciated.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 30, 2016

if you exclude a folder (e.g. node_modules) it will not be included in the compilation. However, if you have an import (e.g. import .. from "@angular\core") it is going to load the required file from the excluded folder. So i guess it is all about the errors you are getting. what are they..

@landonpoch
Copy link

I've seen this be problematic when you are using npm link. When npm link is used you will see both d.ts and .ts files in the node_modules folder for your particular dependency. Then the compiler will try and resolve the imports (and compile them) which would overwrite the d.ts files, which are input files.

I've been able to get around this by doing an npm pack (which honors the .npmignore file) and then extracting, and then linking the extracted package. Kind of a pain, but it works I guess.

@3du4
Copy link

3du4 commented Oct 11, 2016

@mhegazy thank you very much for taking the time to explain!

@benvineyard
Copy link

@landonpoch can you elaborate on the steps needed to npm pack, extract and link.? I am having the problem with an npm linked project.

zsims added a commit to zsims/pact-node that referenced this issue Jan 7, 2018
…onflicts

Per microsoft/TypeScript#7432 the TypeScript compiler will attempt to
compile the TypeScript sources if they're found. This is because definitions (.d.ts) do not take
precedence over source files.
zsims added a commit to zsims/pact-node that referenced this issue Jan 7, 2018
…onflicts

Per microsoft/TypeScript#7432 the TypeScript compiler will attempt to
compile the TypeScript sources if they're found. This is because definitions (.d.ts) do not take
precedence over source files.
@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
By Design Deprecated - use "Working as Intended" or "Design Limitation" instead
Projects
None yet
Development

No branches or pull requests

6 participants