Type is incorrect in ts-node, but correct everywhere else

[NullVoxPopuli]

I'm using a project based of the Typescript-babel starter

open source reproduction: https://github.com/NullVoxPopuli/static-route-paths/blob/master/tests/index.ts#L57
(the actual code in this case)

$ yarn type-check
yarn run v1.15.2
$ tsc --noEmit
Done in 1.17s.

 $ yarn build
yarn run v1.15.2
$ yarn build:types && yarn build:js
$ tsc --emitDeclarationOnly
$ babel src --out-dir dist --extensions ".ts"
Successfully compiled 3 files with Babel.
Done in 1.85s.

Hovering over tree.blogs.show (showing that there is a posts property)

finally, the error:

 $ yarn test --grep "nested level of tokens"
yarn run v1.15.2
$ mocha --require ts-node/register --reporter spec tests/index.ts --grep 'nested level of tokens'

/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/ts-node/src/index.ts:240
    return new TSError(diagnosticText, diagnosticCodes)
           ^
TSError: ⨯ Unable to compile TypeScript:
tests/index.ts:57:40 - error TS2339: Property 'posts' does not exist on type 'Route'.

57         const result = tree.blogs.show.posts.show.with({
                                          ~~~~~

    at createTSError (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/ts-node/src/index.ts:240:12)
    at reportTSError (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/ts-node/src/index.ts:244:19)
    at getOutput (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/ts-node/src/index.ts:360:34)
    at Object.compile (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/ts-node/src/index.ts:393:11)
    at Module.m._compile (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/ts-node/src/index.ts:439:43)
    at Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Object.require.extensions.(anonymous function) [as .ts] (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/ts-node/src/index.ts:442:12)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at /home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/mocha/lib/mocha.js:330:36
    at Array.forEach (<anonymous>)
    at Mocha.loadFiles (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/mocha/lib/mocha.js:327:14)
    at Mocha.run (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/mocha/lib/mocha.js:804:10)
    at Object.exports.singleRun (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/mocha/lib/cli/run-helpers.js:207:16)
    at exports.runMocha (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/mocha/lib/cli/run-helpers.js:300:13)
    at Object.exports.handler.argv [as handler] (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/mocha/lib/cli/run.js:296:3)
    at Object.runCommand (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/yargs/lib/command.js:242:26)
    at Object.parseArgs [as _parseArgs] (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/yargs/yargs.js:1087:28)
    at Object.parse (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/yargs/yargs.js:566:25)
    at Object.exports.main (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/mocha/lib/cli/cli.js:63:6)
    at Object.<anonymous> (/home/lprestonsegoiii/Development/NullVoxPopuli/static-route-paths/node_modules/mocha/bin/_mocha:10:23)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:754:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

{
  "compilerOptions": {
    "rootDir": "src",
    "outDir": "dist",
    "target": "esnext",
    "module": "commonjs",
    "lib": ["es6", "dom"],
    "declaration": true,

    "strict": true,
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,

  },
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "node_modules",
    "dist",
  ]
}

[jcreamer898]

I'm having a very similar issue.

My tsconfig.json has an "include": ["./types", ./"src"] in it.

I have type defs in the types directory to alias some modules that we're loading in our webpack.config.ts file. When I run tsc, all checks out. But, when I try to run webpack, which uses ts-node behind the scenes to load in webpack, it is throwing type errors for things I know I have in the types folder.

My hunch after digging around a bit is this PR. e009d79

I'm not sure why this line exists in that PR?

if (!files) {
   config.files = [];
   config.include = []; // this one?
}

If I comment it out, it properly includes all the type defs I have...

The only solution I have found is to use /// refs at the top of my webpack config to manually include the types.

Thanks! I'll do what I can to help debug the issue further for y'all if needed.

[blakeembrey]

Thanks for the investigation. It sounds like I prematurely marked this as a bug, it’s actually a feature. There’s a section in the README that explains what to do if you’re types are missing. This module doesn’t include everything by default because it slows startup for a simple script like Webpack (you’d end up loading the entire project into TypeScript).

[joonhocho]

I just spent few hours addressing this issues. I was not expecting ts-node to behave differently than tsc, so I assumed there was something wrong with my tsconfig.json file. After digging and trying different things, finally found that there is discrepancy between tsc and ts-node. I think files should be included by default and excluded by choice. It's a bit odd for ts-node to behave differently than tsc in default settings.

[jeremyben]

I agree with @joonhocho, this is an actual unexpected behavior.
When tsc && node main.js works, you expect ts-node main.ts to work as is, since that's the very purpose of this (amazing btw) lib.

Performance-oriented features that break expectations should be opt-in.

Webpack is not used on the backend (or very rarely), and because ts-node decided to ease performance tuning, we're loosing time with a false negative, trying to figure out what mistake we did in our code, before heading to the bottom of the github readme.

And I think you'll continue to have issues from people rightfully mistaking that feature for a bug.

I may sound vehement, but I'm not, and I'd like to thank you for the great work and great care, even in performance related issues like this one, that led to a complicated and necessarily opinionated design decision. 🙂

[joonhocho]

Real problem is that default settings works only until it starts breaking, which is what happened to me. Everything was working fine, but then my project size grew and it stopped working.

[gengjiawen]

--files should be default true. Cause too many problems.