Skip to content

can't run in existing project with node_modules #28

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

Closed
snapwich opened this issue Nov 10, 2015 · 15 comments
Closed

can't run in existing project with node_modules #28

snapwich opened this issue Nov 10, 2015 · 15 comments
Labels

Comments

@snapwich
Copy link

For some reason command line ts-node seems to search the local node_modules folder even when there are no references to it in the file you run. Also, if I run ts-node to get a REPL and execute any command inside a project that has typescript in it, but also have typescript installed globally, I get thousands of duplicate identifier errors.

If I remove typescript from the local project, I get node_modules/autoprefixer-loader/node_modules/postcss/postcss.d.ts (2,22): Cannot find module 'd.ts/postcss'. (2307) node_modules/autoprefixer-loader/node_modules/postcss/postcss.d.ts (3,2): Duplicate identifier 'default'. (2300)

so it appears to search my node_modules folder for all kinds of definitions and then throw a bunch of errors before it evaluates the first line of typescript. I get the same errors running an empty typescript file. Is this expected behavior?

@blakeembrey
Copy link
Member

ts-node requires the typescript module relative to the executable. If you're running ts-node locally, it'll require typescript locally. There's nothing happening globally, unless you have both ts-node and typescript globally. I don't believe there's ever a point where an overlap occurs.

If you have a case where this can be reproduced, I'd appreciate some more details. It sounds like you're running into a TypeScript issue though, and you're using modules that have duplicate type definition references.

@snapwich
Copy link
Author

It seems to be related to my tsconfig.json.

I was able to recreate it in a separate empty repository by having a local [email protected] and [email protected] and a tsconfig.json with the following:

{
  "compilerOptions": {
    "module": "commonjs"
  }
}

this causes any form of ts-node that runs to error out with hundreds of duplicate identifier errors. Is that compiler option incompatible with ts-node?

@blakeembrey
Copy link
Member

Any tsconfig.json file without files specified will automatically glob all files in the directory. It's definitely not incompatible, are you sure this is a completely empty directory?

image

@blakeembrey
Copy link
Member

@snapwich Have you tried using it with tsc? What happens then?

@snapwich
Copy link
Author

this is the contents of the new project

.
./node_modules
./node_modules/.bin
./node_modules/ts-node
./node_modules/typescript
./package.json
./test.ts

so is it globbing through my node_modules then?

@blakeembrey
Copy link
Member

Yes, that's the default behavior of TypeScript too. This describes your issue: microsoft/TypeScript#3289.

@snapwich
Copy link
Author

that looks like the problem. thanks for your help

@snapwich
Copy link
Author

@blakeembrey reading further into this, it looks like this still may be a ts-node problem as far as pulling in files.

on https://github.com/Microsoft/typescript/wiki/tsconfig.json it says "When input files are specified on the command line, tsconfig.json files are ignored." which does seem to be the case with tsc. With the given tsconfig.json above: tsc test.ts compiles the file correctly without globbing through my node_modules but ts-node test.ts seems to ignore the test.ts specified if tsconfig.json is present and starts the globbing.

@blakeembrey
Copy link
Member

That's documentation for tsc, ts-node uses the same behaviour as other loaders and tooling and will import files from tsconfig.json. This is required for .d.ts files to be properly loaded, otherwise you would need to manually recreate the files object in the CLI.

@blakeembrey
Copy link
Member

I could add a --noFiles flag to ignore tsconfig.json files - but it's a pretty bad patch as I imagine you'll need it enabled again eventually for .d.ts files and we'll be back at square one.

Edit: Also, those are conditions in which tsc uses tsconfig.json in it's entirety. We do the opposite and load it by default. If you want to ignore tsconfig.json like tsc does when you specify files, there's already the --noProject flag.

@snapwich
Copy link
Author

I use /// <reference path="./general.d.ts" /> in my .ts files to include .d.ts definitions. Is that not sufficient?

I'm not sure the standard convention for most typescript projects, but a root entry point with typescript references is what was recommended with the webpack typescript loader I am using, which is also why I have a tsconfig.json file in the root folder with no files currently.

@blakeembrey
Copy link
Member

Yes, you can use that. I recommend against references in personal TypeScript projects and would advocate for using files in tsconfig.json instead. They can be used the same way here, except you don't need to duplicate that line into every single file. If you use files in tsconfig.json too, this issue will disappear for you.

@snapwich
Copy link
Author

Unfortunately I can't use tsconfig.json "files" for my webpack typescript loader files, but it would be nice if I could share my tsconfig.json across my client and server-side code.

Is there any harm that would come from having ts-node emulate tsc's behavior of ignoring the tsconfig.json "files" when the entry files are present on the command line?

@blakeembrey
Copy link
Member

@snapwich Why not? What ts-loader are you using, I've reviewed them all at times. That's not what tsc does, when you specify files it ignore the entire tsconfig.json. You can emulate that with --noProject specified.

Edit: Do correct me if I'm wrong though, but I believe those are just "modes" that kick it from tsconfig.json mode into the legacy CLI usage. The CLI existed before tsconfig.json come around.

@snapwich
Copy link
Author

@blakeembrey you're right. it looks like --noProject is the solution for me then. Thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants