4 ms·

FYI, I just tested this, and it seems to work. I was a little concerned about the commentary in the PR about this new mode being "definitely not suitable for De

by veidr 4y ago

FYI, I just tested this, and it seems to work. I was a little concerned about the commentary in the PR about this new mode being "definitely not suitable for Deno", but I think what you want to do is the same thing I've been really irritated that I couldn't do before. Namely, I have an Nx monorepo full of standard TypeScript code, but that code works with a many things: Node, Electron, frontend apps with Angular or Svelte or whatever, etc. I want to use Deno for some new stuff, but Deno couldn't import any of that code without modifying that code so it no longer worked with all the non-Deno stuff. For a quick test, I made a new default Nx monorepo and a regular TS library and a Deno library and a Deno app. I changed all imports to use '.ts', and added this to the tsconfig.json: "moduleResolution": "bundler", "allowImportingTsExtensions": true, ...et voila! My Deno code can finally import all that normal TypeScript code I have sitting around. Haven't tested anything else yet, so I am not sure what, if any, issues those two changes above, plus including the .ts extension, might cause for other existing TypeScript projects.

brundolf 4y ago
Exciting! It's weird to see this: > commentary in the PR about this new mode being "definitely not suitable for Deno" I wonder what they meant by that. I mean, this doesn't magically make all TS code Deno-compatible, but nobody expects it to. What it does do is remove by far the most ubiquitous (and silly) barrier to TS code being Deno-compatible. There are others- system APIs, http imports. But this change allows a whole lot of code that doesn't use those to become compatible
- veidr 4y ago
  Yeah, I didn't get that either, when I read it, but I think what andrewbranch is talking about there[1] is that you might still be able to have problems importing TypeScript code that is using the new "bundle" module resolution — because it may allow other things that Deno doesn't allow. I don't think he is talking about the problem we are, which is that because Deno requires the .ts extension, Deno doesn't actually work with standard, non-Deno TypeScript code (that imports other standard TypeScript code). I mean, until now. I will run some more extensive tests tomorrow or on the weekend, and maybe go comment there if I have something useful to say. But anyway, it seems to me that if, like me, your problem was "Oh no, I cannot import my code into Deno because I cannot add the '.ts' to my imports without breaking it in other TypeScript use cases" then that problem is solved in TypeScript 5. I have the same exact problem at work, except the monorepo is bigger and there are a lot of people who might not be excited to change all their import statements just so my own experimental Deno tools can use their code but... step by step. This seems like a big step for my personal TypeScript projects. :-D [1]: https://github.com/microsoft/TypeScript/pull/51669#issuecomment-1349917006 https://github.com/microsoft/TypeScript/pull/51669#issuecomm...
ddeck 4y ago
>I just tested this, and it seems to work. I was a little concerned about the commentary in the PR about this new mode being "definitely not suitable for Deno" FWIW I've been using version 5.0.0-dev.20230223 for a few weeks specifically for this feature - to share code between TS Vite/web and Deno projects - and it's been working without issue.

by veidr 4y ago

brundolf 4y ago

Exciting! It's weird to see this: > commentary in the PR about this new mode being "definitely not suitable for Deno" I wonder what they meant by that. I mean, this doesn't magically make all TS code Deno-compatible, but nobody expects it to. What it does do is remove by far the most ubiquitous (and silly) barrier to TS code being Deno-compatible. There are others- system APIs, http imports. But this change allows a whole lot of code that doesn't use those to become compatible

veidr 4y ago
Yeah, I didn't get that either, when I read it, but I think what andrewbranch is talking about there[1] is that you might still be able to have problems importing TypeScript code that is using the new "bundle" module resolution — because it may allow other things that Deno doesn't allow. I don't think he is talking about the problem we are, which is that because Deno requires the .ts extension, Deno doesn't actually work with standard, non-Deno TypeScript code (that imports other standard TypeScript code). I mean, until now. I will run some more extensive tests tomorrow or on the weekend, and maybe go comment there if I have something useful to say. But anyway, it seems to me that if, like me, your problem was "Oh no, I cannot import my code into Deno because I cannot add the '.ts' to my imports without breaking it in other TypeScript use cases" then that problem is solved in TypeScript 5. I have the same exact problem at work, except the monorepo is bigger and there are a lot of people who might not be excited to change all their import statements just so my own experimental Deno tools can use their code but... step by step. This seems like a big step for my personal TypeScript projects. :-D [1]: https://github.com/microsoft/TypeScript/pull/51669#issuecomment-1349917006 https://github.com/microsoft/TypeScript/pull/51669#issuecomm...

ddeck 4y ago

>I just tested this, and it seems to work. I was a little concerned about the commentary in the PR about this new mode being "definitely not suitable for Deno" FWIW I've been using version 5.0.0-dev.20230223 for a few weeks specifically for this feature - to share code between TS Vite/web and Deno projects - and it's been working without issue.