Ts-node: Very slow start (with tsconfig.json)

[wclr]

I'm just trying TS and node. Use just:

// index.js
require('ts-node/register')

My server index.js starts about 2 minutes.

If I remove tsconfig.json from root (it can be even empty) server starts normally. What can be the reason for such behaviour?

[blakeembrey]

What version are you using? How big is the project? What additional files are being included?

[wclr]

ts-node the last versions at current moment, typescript 1.8.10 (locally installed in the project)
Windows 10 64x, Node 5.5.0, npm 3.3.12

Protect is not big I would say but many deps. ONE ts file.

Alos I transpile babel using
require('babel-core/register') hook

As I've said it seem to work ok without tsconfig.json

[blakeembrey]

The only reason I can imagine this happening (taking a while) is if you have a ton of subdirectories or a symlink to a ton of directories. When loading, it's doing a glob of files if you aren't using files in tsconfig.json. Can you share your tsconfig.json file?

[wclr]

Well it is actually empty.
Yes I have a quite a lot of npm linked modules, I thought exclude node_modules should help. But it doesn't.
But it seems its ok with "files"

"files": [
  "*.ts"
]

Probably can be closed. Thanks!

[blakeembrey]

@whitecolor That's not how files works, it's not a glob. Given that, I was just checking and ts-node isn't actually doing any resolving of files (just of tsconfig.json). It seems more of the slowness of coming from TypeScript trying to resolve imports then.

[wclr]

Why does then adding "files": ["*.ts"] help?

[blakeembrey]

Because it matches nothing.

[blakeembrey]

Without it, TypeScript starts resolving the files in the current project for compilation. It's possible we can add another hack to make it so it only resolves the files we want and node is accessing.

[wclr]

Babel-core/register works with no prob, should do something like them.

[blakeembrey]

Yes, TypeScript is not Babel. It's not possible to do because it needs to resolve files for compilation (Babel doesn't have a type system so it doesn't care what other files you have).

[threehams]

I have a project with this issue, but it only occurs with nightly builds of 2.0.0. I'll bisect for a bit to see if I can narrow down the release which causes it.

[threehams]

Repro steps are completely different than this one - it's Windows-only, affects ts-node but not tsc, and was introduced with the Typescript 2.0 branch. Go ahead and ignore my report - I need to narrow it down, and it's likely a problem with Typescript itself.

[blakeembrey]

Closing this as answered, feel free to open a new issue or continue the discussion here. If there's a major, reproducible issue with tsconfig.json I'd love to fix it.

[blakeembrey]

@whitecolor By the way, if all you want is something that works like babel and does no type checking, maybe the --fast flag is what you're after.

[wclr]

@blakeembrey Again I'm facing that issue, how is it possible to debug which files are handled by ts-node? Also which tsconfig.json it does use. Some debug ability is really needed, but can not find it.

Does ts-node compiles all the sources when it starts?

[blakeembrey]

@whitecolor It just gives the sources to TypeScript. TypeScript would compile on the first file because it's needed to resolve the dependency tree. I did have some debugging ability the last time around, but I don't think I ever committed it. Happy to add a flag back for it in the New Year or accepting PRs.

[wclr]

@blakeembrey

Nice, It would be great to have some flag that would increase verbosity of the output.

It just gives the sources to TypeScript. TypeScript would compile on the first file because it's needed to resolve the dependency tree.

Does ts-node reuses results of the compilation between runs to speed up sequential runs? (it is quite actual when in development mode with file watching) Or how does it work? I saw before that there was some ts-node folder witch some source cache, but not seeing it now.

[blakeembrey]

There's no way to re-use the compilation between different executions. Within the same execution it doesn't need to re-compute everything, but in a new one it will. There is a cache that is used, but once you encounter a file that isn't in the cache TypeScript will need to kick in.

[Epskampie]

For people find this through google like me, I fixed ts-node starting slow by adding

"exclude": ["node_modules"]

to my tsconfig.json

[wclr]

For people find this through google like me, I fixed ts-node starting slow by adding

"exclude": ["node_modules"]

to my tsconfig.json

Basically one should exclude "**/node_modules/*"

[v1d3rm3]

I'm having same problem. But, when i remove experimentalDecorators": true property or change value to false, it comes fast! @blakeembrey