Open G-Rath opened 4 years ago
@RasPhilCo @jdxcode I've confirmed that removing ts-node
from config
while leaving the rest of registerTSNode
& surrounding code is painless, with the previous functionality being restorable with the following package.json
script:
"cli": "node -r ts-node/register bin/<mycommand>",
Let me know if you're open to a PR
@G-Rath open to this idea. Initial thoughts: 1) Maybe the registering can be handled in a bin/dev shim. 2) We likely need to still back-support for sometime but oclif generators could start producing a new shim
If I understand you correctly, those should be fine - the problem is about that the registering currently exists in oclif instead of userland, so you can't opt-out and have to carry the dependency with you.
So (again if I'm understanding you correctly) having the generator generate a new bin/dev
script for typescript projects that does the registering would be fine since I think that's a cool default to give them and it lets the user remove it if they decide they won't want the ts-node
dependency in their tree.
The above will fail in a typescript project due to
config
setting uptsNode.register
. This is because Jest sees there's already a transformer for TypeScript, and so doesn't apply its own transformer.This is "fine", except that the output of
ts-node
doesn't match the output of Babel (which is what jest uses); when writing inline snapshots, jest looks for alltoMatchInlineSnapshot
matchers by walking the ast as provided by Babel.As such, it fails to find the snapshot matcher because while Babel is walking the AST, it didn't do the transformation, so the line numbers are different and it never finds the matcher.
In general,
@oclif/config
probably shouldn't be using ts-node like this, as it's not really needed: it's encouraging users to ship TS files when they should be compiled, and this behaviour can be replicated in userland by callingtsNode.register
in your bin script, or by passing it tonode
as part of the call (for when testing, which I assume is why this feature was added).Additionally, it's probably going to cause oclif some pain when ESM modules land, as it'll likely force people to stick on commonjs.
Removing
ts-node
would solve a number of issues that have been opened around oclif packages.