4 ms·

The typescript team has some weird hangups around import paths that bring up issues. I wasn't aware of this Deno issue, but there's a similar one with ESM modul

The typescript team has some weird hangups around import paths that bring up issues. I wasn't aware of this Deno issue, but there's a similar one with ESM modules: TS wants you to import "somefile.js" when you actually want "somefile.ts". It's completely non-obvious, and breaks anything that checks if the file to be imported exists on disk.

kybernetikos 5y ago
Yeah, I find this issue very irritating. Forcing you to claim you're importing a file that doesn't even exist except as part of the output of a build step means that you're tying your implementation of a language to a specific set of tooling and environment. It's treating a language like it's a dumb file rewriter rather than something semantically meaningful. It would have made no sense for Deno to do the same thing - if you import a .js file from a remote server, you want that js file, if it doesn't exist automatically trying to load a .ts file from the same location would be pretty odd behaviour. Typescript is a language, the tools should understand it as a language and it should be self-consistent. The other thing that irritates me is that all that typing information is lost at runtime, when it could be very useful in a bunch of situations, but hey, you can't have everything.
- spiderice 5y ago
  In theory, even though this would probably never actually happen, could a browser add Deno to its build and use it to execute Typescript directly without having to rely on Javascript? Seems like a cool way to eventually get rid of the "baggage" that requires Typescript to not have Types at runtime and that sort of thing. edit: And I realize that Deno currently doesn't maintain your types during runtime either, but in theory that would be fixable since it doesn't have to rely on Javascript.
  - harikb 5y ago
    Deno doesn’t execute TS directly - internally it is still JS executed by v8. Having v8 support direct TS will be a huge effort
- rictic 5y ago
  TypeScript is deliberately not a language in the sense that you mean, and this is very much a load bearing part of the design and why it was successful. Many other languages have tried what you're suggesting, most infamously Dart, and all crashed aground on the problem of interoperating with the existing ecosystem. TypeScript is best understood as a very advanced linter for JavaScript, not a separate language with its own semantics that happens to compile to JavaScript. This has many consequences. For example, its type system is unsound to a profligate degree compared to most other typed languages. As a result, it is common for the type system to be wrong about the type of a variable, meaning that any runtime use of type information would have to also cope with being wrong, e.g. by inserting runtime type checks. Runtime type checking for structurally typed interfaces is heinously slow, as you have to type check every field of every transitively reachable interface.

kybernetikos 5y ago

Yeah, I find this issue very irritating. Forcing you to claim you're importing a file that doesn't even exist except as part of the output of a build step means that you're tying your implementation of a language to a specific set of tooling and environment. It's treating a language like it's a dumb file rewriter rather than something semantically meaningful. It would have made no sense for Deno to do the same thing - if you import a .js file from a remote server, you want that js file, if it doesn't exist automatically trying to load a .ts file from the same location would be pretty odd behaviour. Typescript is a language, the tools should understand it as a language and it should be self-consistent. The other thing that irritates me is that all that typing information is lost at runtime, when it could be very useful in a bunch of situations, but hey, you can't have everything.

spiderice 5y ago
In theory, even though this would probably never actually happen, could a browser add Deno to its build and use it to execute Typescript directly without having to rely on Javascript? Seems like a cool way to eventually get rid of the "baggage" that requires Typescript to not have Types at runtime and that sort of thing. edit: And I realize that Deno currently doesn't maintain your types during runtime either, but in theory that would be fixable since it doesn't have to rely on Javascript.
- harikb 5y ago
  Deno doesn’t execute TS directly - internally it is still JS executed by v8. Having v8 support direct TS will be a huge effort
rictic 5y ago
TypeScript is deliberately not a language in the sense that you mean, and this is very much a load bearing part of the design and why it was successful. Many other languages have tried what you're suggesting, most infamously Dart, and all crashed aground on the problem of interoperating with the existing ecosystem. TypeScript is best understood as a very advanced linter for JavaScript, not a separate language with its own semantics that happens to compile to JavaScript. This has many consequences. For example, its type system is unsound to a profligate degree compared to most other typed languages. As a result, it is common for the type system to be wrong about the type of a variable, meaning that any runtime use of type information would have to also cope with being wrong, e.g. by inserting runtime type checks. Runtime type checking for structurally typed interfaces is heinously slow, as you have to type check every field of every transitively reachable interface.