ts-node executable hangs, won't enter repl

[whistlerbrk]

I never reach the repl, only ts-node -h works, I can't even print a version.

maybe some useful debugging information?

kshah ~ npm install -g ts-node
/Users/kshah/.nvm/versions/node/v8.9.4/bin/ts-node -> /Users/kshah/.nvm/versions/node/v8.9.4/lib/node_modules/ts-node/dist/bin.js
+ [email protected]
updated 1 package in 1.427s

kshah ~ which ts-node
/Users/kshah/.nvm/versions/node/v8.9.4/bin/ts-node

kshah ~ which npm
/Users/kshah/.nvm/versions/node/v8.9.4/bin/npm

kshah ~ npm --version
6.4.1
kshah ~ node --version
v8.9.4

It appears to failing here:

ts.parseJsonConfigFileContent(config, ts.sys, basePath, undefined, configFileName);

which is a call made in readConfig

the arguments provided to this parseJsonConfigFileContent function are as follows:

{ config:
   { compilerOptions:
      { sourceMap: true,
        inlineSourceMap: false,
        inlineSources: true,
        declaration: false,
        noEmit: false,
        outDir: '$$ts-node$$' } },
  'ts.sys':
   { args: [],
     newLine: '\n',
     useCaseSensitiveFileNames: false,
     write: [Function: write],
     writeOutputIsTTY: [Function: writeOutputIsTTY],
     readFile: [Function: readFile],
     writeFile: [Function],
     watchFile: [Function],
     watchDirectory: [Function: watchDirectoryUsingFsWatch],
     resolvePath: [Function: resolvePath],
     fileExists: [Function: fileExists],
     directoryExists: [Function: directoryExists],
     createDirectory: [Function: createDirectory],
     getExecutingFilePath: [Function: getExecutingFilePath],
     getCurrentDirectory: [Function: getCurrentDirectory],
     getDirectories: [Function: getDirectories],
     getEnvironmentVariable: [Function: getEnvironmentVariable],
     readDirectory: [Function: readDirectory],
     getModifiedTime: [Function: getModifiedTime],
     setModifiedTime: [Function: setModifiedTime],
     deleteFile: [Function: deleteFile],
     createHash: [Function: createMD5HashUsingNativeCrypto],
     createSHA256Hash: [Function: createSHA256Hash],
     getMemoryUsage: [Function: getMemoryUsage],
     getFileSize: [Function: getFileSize],
     exit: [Function: exit],
     realpath: [Function: realpath],
     debugMode: false,
     tryEnableSourceMapsForHost: [Function: tryEnableSourceMapsForHost],
     setTimeout: { [Function: setTimeout] [Symbol(util.promisify.custom)]: [Function] },
     clearTimeout: [Function],
     clearScreen: [Function: clearScreen],
     setBlocking: [Function: setBlocking],
     bufferFrom: [Function: bufferFrom],
     base64decode: [Function: base64decode],
     base64encode: [Function: base64encode] },
  basePath: '/Users/kshah',
  configFileName: undefined }

That's as far as I've taken the debug. Hoping someone can point me in the right direction

[whistlerbrk]

Okay, it looks like if I pass the -P option I can get the REPL to load

It seems like configFileName should never be undefined but clearly there is a code path which allows this

[thehappycoder]

I have the same problem

$ ts-node

never gets to prompt. It seems to be doing something. I can see that by CPU usage.

I am running global ts-node

192-168-1-4:~ anton$ node -v
v10.6.0
192-168-1-4:~ anton$ tsc -v
Version 3.0.3

[whistlerbrk]

@thehappycoder not sure if you saw my follow up comments here, pass the -P option and give it a blank config perhaps and you should be fine

[whistlerbrk]

(obviously not ideal and clearly this is an actual problem)

[blakeembrey]

This is, unfortunately, how TypeScript works with an empty project. If you're initializing on a huge directory it will traverse the entire thing looking for all .ts files. The solution is probably to block you from using ts-node without a project file.

[blakeembrey]

@whistlerbrk Would you like to comment on what you feel the correct solution is?

[whistlerbrk]

options:

1. sane defaults
2. sane defaults, plus a warning that a default config is being used
3. erroring out if a config file isn't passed

I think 1 or 2 is best. People want to install something and use it, not configure it first, it isn't a great experience for newcomers.

[blakeembrey]

@whistlerbrk And what is "sane defaults"? Why isn't the current configuration "sane"?

[whistlerbrk]

Because it hangs? and provides no error message? Are we seriously debating whether launching an executable and it not doing anything, not returning access to the REPL, and not failing is okay behaviour? I must be missing something here

[blakeembrey]

@whistlerbrk I'm not debating anything, I'm just wanted to understand what sane behaviour is to you so I don't waste time implementing something you don't think is sane. You didn't exactly specify any behaviour in your comment, you just said "sane defaults". Obviously, when originally implemented, it appears this was sane (as opposed to insane).

[whistlerbrk]

@blakeembrey fair enough, apologies for the tone.

There is no current configuration essentially.

Further, --project / -P is presented as an option, not an argument or a parameter, making it seem like it is not required.

A confused user may then see --skip-project which makes it seem like --project won't be required, but that doesn't appear to what that flag does either.

I say sane as in, reasonably modern defaults, definitely something that is up for debate, anything is better than nothing is all.

[blakeembrey]

That makes sense. Generally it is an option because I tried to make ts-node mirror tsc. By default it resolves tsconfig.json like tsc recursively upward. When it fails to find anything, tsc would normally error out and print the "help" dialog. Which option do you prefer:

1. Mirror tsc, fail when no tsconfig.json file is found.
2. When no tsconfig.json file is found, use an in-memory tsconfig.json file with files: [] (so it won't fall back to the current behaviour of traversing everything in the cwd)

[whistlerbrk]

Interesting, I suppose the first makes more sense if the goal is to mock tsc, however, I think of REPLs as interactive playgrounds first, so I still think the second is best.

[whistlerbrk]

Thank you @blakeembrey !

[blakeembrey]

@whistlerbrk It won't be released for a bit until 8.0, since it is a breaking change (with the others). I did, unfortunately, notice an issue with my fix since --files won't work with the change. Debating whether that feature should be removed in 8.0 or whether this bug should persist with ts-node --files.

[szhu]

It would be great if there was a command+args (for example, ts-node --defaultConfig you can type in any working directory that got you a ts-node using the default config, even if there is a tsconfig in the same directory. I think this would be great as a debugging tool, especially as a one-liner that I can give to others who are looking an easy way to set up a TypeScript playground.

I'm not 100% clear on what change #700 makes. Let me know if it addresses this.

[blakeembrey]

I think it addresses that. It just loads the default REPL without any config. This issue was a problem with TypeScript treating no file input as search all directories. If you do ts-node in a project or empty directory, you’d see the expected behaviour.