Ts-node: cli tools currently not possible due to sourcemap issues

[philkunz]

Currently you can't write cli tools with ts-node that are not meant for requiring. It is possible to execute them at some point when removing node_modules from the ignore array, but for some reason there are issues with sourcemaps. Funnily enough the transpiled files land in the cache on disk first. So after a few tries the cli tool will run (when all files are cached). Pretty weird. I tried to debug it, but it doesn't really help.

You can try it out by running npm install -g @gitzone/[email protected] and then running gitzone -v a few times. Other commands to try are gitzone commit

[blakeembrey]

Publish your module as JavaScript.

[philkunz]

@blakeembrey I think with ry/deno on the horizon, modules that are not meant for requiring have a point in being written and published in TypeScript. That ensures an upgrade path once it hits :)

[blakeembrey]

I don't think it does. Deno doesn't use NPM, it uses HTTP, so things would _just work_ anyway.

[blakeembrey]

In any case, this won't be supported for the reasons mentioned in the README.

Edit: As for the source map issues, definitely feel free to submit a PR for it. I would like it to work, but it can't be the default behaviour.

[blakeembrey]

Also, FWIW, since deno doesn't do extension resolution like node.js does, I don't think it'd be possible to support both within the same module. TypeScript doesn't rewrite import paths to the .js file during transpilation. You'd end up with every single NPM module requiring ts-node/register and that will explode since there is different configurations for each one.

[philkunz]

Wait, I'm only speaking of CLI tools being written in TypeScript. That means it will never be npm installed except globally or as save-dev. For all other modules I agree that the API should be consistently JavaScript with types for those who who want it. But for cli tools I pretty much think all TypeScript is the way to go.

[philkunz]

And since we have ts-node why not make it work for globally installed modules that noone is supposed to require in any third party project? It would save a lot of boilerplate.

[blakeembrey]

How would you support that? There's no inherent difference between a global and local module. Also, I assume you're somehow registering ts-node for this global module? Couldn't you, in this case, change the ignore config?

[philkunz]

yes, I set the skipIgnore option. But errors keep popping up, due to source-maps having pathing issues. This occurs when calling the global module from outside the same filebranch, or in other words when process.cwd() points to another directory than the globally installed ts files.

[philkunz]

Is there any reason why you don't transpile files with inline sourcemaps? I think it would solve a lot of the headaches. But right now that is more intuition. I have to keep looking into it.

[blakeembrey]

They are transpiled with inline source maps: https://github.com/TypeStrong/ts-node/blob/55741b643d917e47db164cd7dbab2fba25042619/src/index.ts#L570-L576.

[philkunz]

So why are there two files asked for in the output:

https://github.com/TypeStrong/ts-node/blob/55741b643d917e47db164cd7dbab2fba25042619/src/index.ts#L373-L384

and the default typescript options say inline sourcemaps false?

https://github.com/TypeStrong/ts-node/blob/55741b643d917e47db164cd7dbab2fba25042619/src/index.ts#L118-L128

[philkunz]

updated previous comment with the right lines.

[blakeembrey]

Did you try reading the code? You'll notice that I need to make modifications to the source map contents before serializing it inline. This is because the source map emitted by TypeScript maps the paths incorrectly for node.js.

[philkunz]

I tried yes, but I'm not 100% understanding it yet. Otherwise I would have made a fix for my problem and made a PR. I get it.

[blakeembrey]

I'm just pointing out the fact that if you looked at the code, you would see the source map is being inlined where I pointed to previously: https://github.com/TypeStrong/ts-node/blob/55741b643d917e47db164cd7dbab2fba25042619/src/index.ts#L575

It doesn't make a ton of sense to inline it with TypeScript just to decode it, parse it, stringify it and encode it again. Instead I skip the first step by getting the output as JSON and then doing the subsequent steps myself.

[philkunz]

Somewhere there lies the problem though, since I'm running into that

https://github.com/TypeStrong/ts-node/blob/55741b643d917e47db164cd7dbab2fba25042619/src/index.ts#L376-L379

when I'm just requiring the .ts file, yet a transpiled version lands correctly in cache... And everything runs smoothly when I'm within the same file branch (as in I don't diverge with cwd into a another branch where I have to walk up a few levels and then back into another branch to the globally installed ts files)

[blakeembrey]

Without a reproduction I wouldn't be able to debug. I can't imagine how your getting no output but something goes into the cache because it's not possible. It is possible that you are requiring a file that requires another file that looks like a .d.ts file because there is no output and the first file would land in the cache correctly.

[philkunz]

but then shouldn't work in the same directory either? The CI builds (same cwd in CI and also going into the same global directory when installed) works flawlessly:

https://gitlab.com/gitzone/gitzone/-/jobs/78633118

[blakeembrey]

I imagine it should. I don't see your code hitting the error you pointed out, but I do see JSON parsing issues. And 20 minutes later I realised you just copied these files into your project but omitted that error so I just wasted a bunch of time debugging for you.

This looks like a TypeScript issue since it's emitting no code.

Edit: I see you did include the license 👍 Still, it would have been nice to notify me before I spent too long trying to replicate an issue you had "removed".

[blakeembrey]

Given the fact that there's no output, it's most likely https://github.com/Microsoft/TypeScript/issues/11946.

[philkunz]

oh, I'm truly sorry for this :( I was trying to debug it, and pushed some things in order to replicate the npm install -g behaviour. I will try next time.

[blakeembrey]

No problem. I was a bit dumbfounded for a while because it should have been impossible to hit the JSON.parse error. It just meant I spent time looking in the wrong place. I believe this _may_ be worked around in ts-node by overriding the default include and exclude paths to include node_modules so it doesn't take the implicit argument from TypeScript (see linked issue), but I'm not in a rush to resolve it right now. Feel free to submit a PR if you find a way to work around it comfortably. Just note, however, this may have ill side effects on anyone using --files since it would possibly result in loading all of node_modules sources on startup.

[philkunz]

That is a valuable hint. I will try :)

[philkunz]

I thought about it long and hard. I think I'll compile to JavaScript for now. It does not really hurt me, and I'm looking out for the issue you linked and will retry once its fixed.

Thank you for your time. I really appreciate your work here, given that with your knowledge within the TypeScript space you could also use that time to work for a really high hourly wage on closed source, ... and as nature wants it you can spend every hour only once. :) So the least I can do is looking for an "coffee button", but couldn't find any on the project readme?

Thanks again and have a great day!!!