feat(ts-node): BREAKING CHANGE execute ts files directly

[aorinevo]

BREAKING CHANGE

Background

The motivation behind this change is to explore what is possible with TypeScript (TS). Whether or not we actually want to move to executing TS directly is still an open question that comes with non-trivial tradeoffs. For example,

• We take a performance hit in executing TS directly via ts-node, however, if we were to do so within a Deno environment, the performance is comparable to javascript.
• We improve developer experience and workflow as developers do not need to worry about transpilation setup and issues. For example, upgrading to latest ora, commander, and log-symbols is non-trivial and most of the complexity is a result of the new major versions of those packages being of type module (esm) vs commonjs.
• We require global installation of ts-node which is not something customers needed to worry about or even think about previously.

Changes

Currently we transpile ts files to js, as files are executed in NodeJS environment which doesn't support direct execution of ts files. These changes enable ts files to be executed directly through ts-node.

This PR also contains:

• updates to renovate configurations.
• move of jest configuration to standalone file.

Notes

1. Assumes ts-node is installed globally.
2. ts-node is widely adopted in the NodeJS and TS communities for executing TS code directly without requiring a separate compilation step.
   • Download count on npm: 19.5+M/week
   • Last update: 4 months ago

Alternatives

1. Instead of ts-node, use Deno

[nwalters512]

Can you say more about the motivations behind this change? What do we gain by directly executing TS files and forcing consumers to have ts-node globally installed?

[aorinevo]

Can you say more about the motivations behind this change? What do we gain by directly executing TS files and forcing consumers to have ts-node globally installed?

@nwalters512, I hope all is well. I've added more details to the PR description to address these questions. Thoughts?

[nwalters512]

Thanks for adding more details! Responding to each point:

• I'm nait sure how Deno is relevant here. Is your thinking that we'd require Shepherd to be executed via Deno? That seems like a non-starter to me.
• Just running code through ts-node won't leave us open to using ESM packages without further changes. We'd need to set up our TypeScript config to emit ESM and set an appropriate type inpackage.json. But once we do that, the transpiled code would just work for consumers; there's no need to directly execute untranspiled TypeScript.
• This seems like pure downside, and I've never seen a project do this.

If all you're worried about is the experience of folks developing Shepherd, we can certainly use ts-node in dev flows. Or even https://github.com/privatenumber/tsx, which I personally like much better since in my experience it supports native ESM much more seamlessly. But I see no reason to change how things work for folks who are just installing the package. I see no upsides, just downsides.