-1

I read this article on how to run a typescript file on the command line, and it appears to be working, but VS Code is reporting invalid errors:

enter image description here

You can see from the terminal (bottom half of the picture) that this file runs without issue. According to the lower right-hand corner, VS Code recognizes the file as typescript, but it doesn't recognize any libraries in its environment.

Perhaps it thinks this is configured for web instead of node? I do have evidence for that: it auto-completes the contents of window and document. Is there some way I can tell VS Code that this is a node environment?

It's worth noting that VS Code is running in an Ubuntu WSL terminal/environment on Windows 10. There is no tsconfig.json file involved. It's using whatever's the default. This "script" sits in my personal /bin directory alongside other bash shell scripts. As such, I'm trying to avoid all the boilerplate of setting up an entire TS project to get this working.

Update: That error on fs suggested a "Quick Fix" to install node types. I ran npm i --save-dev @types/node and the error went away, but it created a "node_modules" directory. Since "node_modules" doesn't seem necessary to execute the script, and since it will be used by the next ts shell script I put in that bin/ directory, I'm hoping there is another solution.

I'm trying to avoid creating a project / node_module dir / tsconfig.json / etc. to solve this as my intent is to write a shell script in typescript instead of bash. One of the benefits of shell scripts is you can just create a file and run it; you don't need much, if any, boilerplate.

starball
  • 20,030
  • 7
  • 43
  • 238
Daniel Kaplan
  • 62,768
  • 50
  • 234
  • 356
  • Does this answer your question? [How can I make vscode assume a node.js context, so that it doesn't assume \`fetch\` exists?](https://stackoverflow.com/questions/73364860/how-can-i-make-vscode-assume-a-node-js-context-so-that-it-doesnt-assume-fetch) – starball Apr 05 '23 at 03:16
  • @user Sorta... To me it's more like a workaround: I'm trying to avoid creating a project/node_module dir/tsconfig.json/etc. to solve this as my intent is to write a shell script in typescript instead of bash. One of the benefits of shell scripts is you can just create a file and run it; you don't need much, if any, boilerplate. Your answer does help though, and I've edited my question to make it more distinct. – Daniel Kaplan Apr 05 '23 at 03:48
  • @user totally viable; I was just hoping to find a way to avoid it. I'll accept that as an answer. One of the downsides is it interferes with my ability to create a temporary, ad-hoc script in any directory. I'm kinda on the fence about whether or not this is a duplicate: I think I'm going to create a VS code feature request that allows me to tell it what to config to use when one doesn't exist. Or maybe I'm missing something: if the command line can figure it out, why shouldn't VS Code have a way, too? – Daniel Kaplan Apr 05 '23 at 04:25
  • "_if the command line can figure it out, why shouldn't VS Code have a way, too_" in the general case, because VS Code is a general-purpose editor, while ts-node is a specialized type of TS/JS runtime, with specific module resolution behaviour, target platform API (NodeJS API), etc. What could be nice here is a VS Code extension that looks for a ts-node shebang and then kicks in with ts-node-specific IntelliSense. – starball Apr 05 '23 at 04:34

1 Answers1

1

I don't think you can avoid having to have a node_modules/ or tsconfig.json/jsconfig.json somewhere on your machine. You'll need the node_modules/ if you want to get TypeScript typings (and by extension, typings-related IntelliSense in VS Code) for the NodeJS API, and you'll need the tsconfig.json/jsconfig.json to tell VS Code to understand things like module resolution. They key to the question is how many you can go down to, and where to put it.

For NodeJS itself, its module resolution logic can be found in the docs, and summarized in the TypeScript module resolution docs, along with the description of TypeScript's module resolution logic. Basically, if you only want to have one node_modules/ and corresponding tsconfig for all you ts-node scripts, then just install @types/node and put your tsconfig.json at the lowest directory that is an ancestor of all your scripts.

You'll have to open that folder containing the tsconfig.json and node_modules/ as the VS Code workspace folder to get IntelliSense for the scripts within.

This may not be very ideal depending on where your scripts are all located, but I don't personally know of a better way at the current time.

starball
  • 20,030
  • 7
  • 43
  • 238