Be a tsc.

[KnorpelSenf]

I would love deno2node to behave exactly like a tsc that is Deno-aware. I see this as the main advantage over dnt—instead of having some magic black box that somehow tries to do everything, it would be awesome to do just one thing, and do it really well: compiling Deno code for Node.

That way, we could use our existing Node workflows that are based around tsc, and use deno2node as a drop-in replacement once we move to Deno. As a result, all existing infra and Node tooling will keep on working. I cannot imagine how dnt is going to solve denoland/dnt#60 in the foreseeable future, but deno2node already integrates seamlessly with Node workflows.

At the same time, it enables us to write Deno code most of the time. We can use all their tooling, hosting, docs, infra, and all other advantages. On the Node side, in contrast to dnt, we still remain in control of our own configs and setup. In a way, deno2node brings the best of both worlds, because we can target both platforms natively, and use the familiar tooling of both ecosystems.

Some points that would be amazing to see are the following.

• deno2node --init creates a clean project from scratch which targets both Deno and Node.
• deno2node runs without a file path to tsconfig.json, and it behaves like tsc would do without config file.
• deno2node supports those compiler options that make sense from https://www.typescriptlang.org/docs/handbook/compiler-options.html#compiler-options

[KnorpelSenf]

The point would be to make Deno code a first-class TypeScript complication source. If your project compiles, you can make it compatible with Deno and it'll still compile.

[wojpawlik]

One could re-use TypeScript's argv parser...

[KnorpelSenf]

That would indeed be pretty cool! I find feature parity with tsc a pretty compelling argument. It's amazing for complex projects that may rely on tsc a lot. It's also amazing for beginners because they're familiar with the interface of tsc so they can trust that the learning curve is flat.

[wojpawlik]

Way too complex, I'm not interested in rolling my own scaffolding tool from scratch...

[wojpawlik]

...At least until deno2node is a drop-in tsc replacement

[KnorpelSenf]

Maybe we can think differently about handling the complexity. All of git, tsc, npm handle --init the same way, they generate all necessary data from code. None of them actually ship any files to be created.

What is the minimal setup that would work for d2n? For example, I can use a TS project by simply creating src.ts and putting some TS inside and then running tsc. It would be cool if the same was possible with d2n.

At the same time, tsc --init generates a single config file from the options it supports. Hence, when it starts supporting new options, tsc --init will automatically include them next time. Is there a thinkable setup where d2n also only needs a single config file? How would this look?

[wojpawlik]

Everything in https://github.com/fromdeno/template is useful to some degree:

• .editorconfig -- useful for text editors
• .github/workflows/ci.yml -- useful for GitHub
• .gitignore -- required
• .vscode/extensions.json -- useful for VSCode
• .vscode/settings.json -- required by VSCode
• package.json -- required by (p)npm
• src/mod.ts -- useful
• src/shim.node.ts -- required by tsconfig.json
• tsconfig.json -- required by deno2node

[KnorpelSenf]

• .editorconfig -- useful for text editors

Useful, not required. Drop.

• .github/workflows/ci.yml -- useful for GitHub

Useful only on GitHub. Drop.

• .gitignore -- required

Useful only in git. Drop, but print message if in git which folders to ignore.

• .vscode/extensions.json -- useful for VSCode
• .vscode/settings.json -- required by VSCode

Useful only with this editor. Drop.

• package.json -- required by (p)npm

Generate. Values could be chosen dynamically. Do not store a static file.

• src/mod.ts -- useful

No other tool defines entry points. Unexpected. Drop. Optionally, print link to getting started guide.

• src/shim.node.ts -- required by tsconfig.json

Change config. Not all projects need this. (Example: grammY runner.) Drop.

• tsconfig.json -- required by deno2node

Tap into tsc to generate dynamically. Then, add empty d2n config for illustration purposes.

[wojpawlik]

• .gitignore -- required

Useful only in git. Drop, but print message if in git which folders to ignore.

Weird middle ground. At that point, might as well create it.

• tsconfig.json -- required by deno2node

Tap into tsc to generate dynamically. Then, add empty d2n config for illustration purposes.

#21 already modifies the deno2node's tsconfig.json so that it can be "copied" to the new project. Feel free to resurrect the PR.

[wojpawlik]

npx deno2node --init would be sweet

[wojpawlik]

Actually, I'll resurrect it today

[KnorpelSenf]

Reopening to keep track of the other ideas mentioned here

[wojpawlik]

Summarizing:

1. I'm happy to merge PRs adding useful CLI flags. We already added --noEmit and --init.
2. I'd be happy to see a (possibly breaking) PR switching to TypeScript's CLI parser, even tho I'm starting to like x/cliffy: