Deno: Clarification regarding distributing TS source code instead of JS

[deebloo]

If this isn't the best place to post this please let me know and I will close and will ask elsewhere.

In the current day typescript world it is best practice to distribute compiled javascript alongside .d.ts files. This means that the end user doesn't need to worry about compiling the source code.

I know that Deno supports .d.ts files but it doesn't seem to be the preferred method based on the documentation/examples and I also see that it is limited (which makes sense).

What I have seen so far is that each user is fundamentally responsible for compiling a module's typescript code. This means that the user environment (Deno version, TS version, TS conifg, Deno config) would need to be the same/compatible with the authors environment.

Case:
Module author distributes a module where they use a custom tsconfig with more lax compiler options. (ex: sets strictNullChecks to false)

Result:
An end user using the default strict compiler options would potentially NOT be able to compile and run the module.

The other place this shows up is modules depending on the --unstable flag.

I am concerned this issue will continue to come up as the ecosystem grows and especially as new Typescript versions are released. Is there guidance for how to avoid the issues above?

Thanks for the great work! I hope to be able to contribute more than long github issues in the future.

EDIT: here is an example repo that demonstrates the potential issue I am thinking about https://github.com/deebloo/ts-dist-options

[kitsonk]

In the current day typescript world it is best practice to distribute compiled javascript alongside .d.ts files.

Common practice or best practice. Most runtimes don't support TypeScript as a first class language, ergo, there is little choice. That doesn't make it best practice.

Module author distributes a module where they use a custom tsconfig with more lax compiler options. (ex: sets strictNullChecks to false)

JavaScript + .d.ts files would effectively be the same problem if Deno were to type check the .d.ts files. We are working on a --no-type-check option which would simply not enforce the type checking (#5436).

The other place this shows up is modules depending on the --unstable flag.

Again, distributing as d.ts files doesn't solve this problem.

We have discussed the TypeScript version issue. In the end, supporting _n_ versions of TypeScript in the same runtime compiler doesn't help anyone in the long term. It simply drags around old code. Almost all of the "breaking" TypeScript changes make code more sound, or catch errors that were previously uncaught. It is actually better for everyone if we break that code, with an escape hatch of --no-type-check.

Another way to "fix" code for distribution, would be to use deno bundle. Currently deno bundle doesn't emit a .d.ts file (See: #3385) but that would effectively give what you are suggesting. Again, I don't think it really fixes the problems you highlight, because again the .d.ts file would reflect the environment it was built in, causing the same problems as if you were consuming TypeScript directly.

[deebloo]

Common practice or best practice. Most runtimes don't support TypeScript as a first class language, ergo, there is little choice. That doesn't make it best practice.

I would argue it is best practice because there ARE folks that prefer to distribute shared code as raw TS. (usually seen in internal teams from my experience) It is not nearly as common but it does happen. The scenario I outlined above is the reason not to do it.

JavaScript + .d.ts files would effectively be the same problem if Deno were to type check the .d.ts files.

I am not sure that is true. but could be missing something.
I created a small reproduction that demonstrates the issue I am talking about using tsc directly.

https://github.com/deebloo/ts-dist-options

This may be a non issue with Deno but I wanted to be certain. This would largely only cause issues with folks who use custom "tsconfig.json" which at least at this point does not seem very common.

One Deno version supporting one Typescript version also makes sense. Is it possible for a user to provide a different version or is it locked to the version that is installed with Deno?

[brianleroux]

I am of the opinion that given TypeScript has both a history of breaking changes and 31 boolean configuration options for the compiler the only sensible approach is to publish and consume JavaScript (which is backwards compatible) and leave the TypeScript as a purely authortime concern (since it is anyhow).