Is it possible to edit client, server, and shared TypeScript files all at once?

[TradeIdeasPhilip]

Is your feature request related to a problem? Please describe.

I want to use shared TypeScript libraries between the client and the server. Even when I'm working on files that are specific to one side or the other, I still want them all in the same IDE at the same time.

Describe the solution you'd like

I've created a template to show how far I've gotten, and where I'm stuck: Deno Client Server Template. I'm running into two major problems.

• When I try to load a Deno project and a normal TypeScript project into the same VS Code workspace, VS Code gets very unstable. (Looks like a bug.)
• When a shared TypeScript module tries to import another shared module, do I add the ".ts" to the end of the file or not?

I'd love to know how other people handle these issues. Is there already a working template out there? Is there a fix or work-around I can do on my side? Or do I need to wait for bug fixes and/or new features?

Thanks!

[TradeIdeasPhilip]

Here's some relevant info from Microsoft's TypeScript team. To help bridge the gap between TypeScript and modern JavaScript modules, they added an interesting feature. If you say import { yada } from "./yada.js"; TypeScript will know that you are actually talking about yada .ts at compile time. But it will leave import { yada } from "./yada.js"; in the final JavaScript file it creates. It's ugly, and the reviewers on GitHub hate it, but it solves a problem. You can now use TypeScript to generate JavaScript files that a modern browser can read without adding any 3rd party libraries, obfuscators, bundlers, etc.

It pains me to ask, but would you consider adding the same feature to Deno? If Deno knows that import { yada } from "./yada.js"; actually means import { yada } from "./yada.ts";, then I can add statements like that in my shared library files. Deno and a normal browser client will both be able to use the same TypeScript library files, even the ones that reference additional TypeScript library files.

[Soremwar]

@TradeIdeasPhilip Oh, nice seeing you here. You see Phillip, the problem is that if you tell an OS to look for mod.ts and mod.js it will see them as individual, separate files.

Deno works the same way, right now you can have two files file1.js and file1.ts, both with different content and import them both in your code, cause essentially they are different files that have nothing to do with each other.

[TradeIdeasPhilip]

Here's the solution that I'm on the verge of.

Run two separate instances of VS Code, one with the Deno files and the other with the client and shared files. To avoid VS Code crashing.

Create a script which will watch the client's library directory. Any time a *.ts file changes, automatically copy it to the server's library directory. And create a sed script to change /(?<=import.from ".)js(?=")/ to "ts" in the server's copy. And mark the server's copy read only so I don't accidentally edit the wrong copy.

@Soremwar , yeah, my suggestion to follow Microsoft was somewhat tongue in cheek. But I feel like I'm missing something.

I know I'm not the first person to try to reuse a module between the client and the server. The default template for new GWT projects comes with a client, server, and shared directories, for example! Surely someone's done this in JavaScript? It's frustrating because I can see how close I am. For goodness sake, Deno goes out of it's way to match the modern Browser's built in libraries. What was the intent of that?

It really seems like there is a very simple solution close by. https://www.youtube.com/watch?v=yijQRhPvJhQ

[Soremwar]

@TradeIdeasPhilip I just think that you are overcomplicating things too much. I don't know why do you need two instances of VSCode running to be honest, there is probably something wrong with your setup.

Transpiling the code you already have should be just enough, or am I missing something? Since the code you already have in TS and the final code in JS for the browser are going to be pretty much the same

[TradeIdeasPhilip]

I don't know why do you need two instances of VSCode running

When I try to run with normal typescript and Deno typescript in the same instance of VS Code, VS Code frequently crashes. It's very repeatable. Go to the code I posted and open the workspace at the top level. This is a bug. I'm assuming it's a bug in Deno's VS Code component, so I reported it on this project.

or am I missing something? Since the code you already have in TS and the final code in JS for the browser are going to be pretty much the same

It's almost identical. That's why I'm so frustrated. I can basically make it work if I'm willing to put ".ts" into all my exports, then start my Deno software running, then changes those exports to say ".js" and then call tsc on my web facing files.

If you look at my example you will see that I got close. The server side main program and a client side script both share the useful-stuff.ts library.

However, my server script is not able to access my high-security.ts library. The difference is that my high-security.ts library references the useful-stuff.ts library. That's the point where I get stuck. Short of changing line 1 of high-security.ts every time I switch between client work and server work, I can't make any progress.

I want to share a typescript library between Deno and the browser. In this example, I want to uncomment line 4 of my server script so I can import that typescript library file.

[Soremwar]

@TradeIdeasPhilip I opened a PR in your repo that tries to come close to the structure you should have in order to share files with Deno and the browser, so further discussion can be carried there if you have any doubts (this is an issue tracker so not really a place to ask questions like this)

[TradeIdeasPhilip]

Thanks, @Soremwar , I'm looking at that now.

Were you able to reproduce my problems with a multi root workspace? It appears that the Deno extension doesn't work well in that case. I think I need to move that bug into it's own issue report.

It's hard for me to describe because the details change every time I try it, but I've never gotten it to work right. (100% repeatable that something goes wrong, but it looks different every time.) This morning, for example, the Deno extension is trying enforce rules on things outside of my deno/ folder. In the past the problem usually went the other direction.

[TradeIdeasPhilip]

@Soremwar I'm still looking at all the tricks you used. However, I don't think this will solve my biggest problems.

Sadly one thing that I couldn't fix is the definitions for the DOM

I should have been more clear. This is at least my 3rd serious prototype of this project. I had already solved the DOM issue in my second prototype. That was too ugly, so I wrote this 3rd version from scratch.

I've tried working in TypeScript when TypeScript was looking at the wrong libraries. That was terrible. I would go back to plain JavaScript before I'd use TypeScript with the wrong libraries again. Better to have no one trying to enforce the rules than an AI that's wrong a lot!

I look forward to investigating the bundler, starting with the code in your PR. It sounds like that will solve my problem with the file extensions. However, the bundler is downstream from the editor. If we could just get Intellesense working in the editor, we might be done!

Note that I have three directories full of *.ts files. Each one requires different libraries. I attacked that problem by creating different tsconfig files in the web directory and the shared directory. I relied on the defaults built into Deno for the third. That's what I want fixed. I think it's a legit bug report / feature request for the vscode_deno project. I know Deno doesn't like tsconfig files, but we need to way to tell the TypeScript service that different directories use different libraries. It works outside of Deno. It seems like an oversight in the deno plugin, like no one thought to test it.

PS Thanks for fixing the directory bug in my server. This is just a prototype. There are a lot of small holes in the code. I'm really focused on a proof of concept. I want to make sure Deno can fulfil my basic requirements before I get lost in the details.

[kitsonk]

I think this can be solved with "workspace folders" which we will add to the Deno language server and the extension.

[nettybun]

Run two separate instances of VS Code, one with the Deno files and the other with the client and shared files. To avoid VS Code crashing.

My team and I have also been doing this.

• One VSCode for /project which views /project/client/**.ts and _/project/shared/**.ts. Using ESLint, Typescript, etc.
• Separate VSCode for /project/server/ (Deno uses the /project/server/.vscode/ settings)

This way Deno's formatter/linter/etc doesn't choke on any non-Deno TS files. If you accidentally view and save client/shared code in the Deno editor it'll format/rewrite the file.

Hoping we can soon tell Deno to ignore directories 🤞🤞

---

It gets messy when I want to use Deno as a general purpose script runner. Where should project wide build scripts live? The project root...ohno.