pmizio / typescript-tools.nvim

⚡ TypeScript integration NeoVim deserves ⚡
MIT License
1.26k stars 36 forks source link

How to control tsserver process launch or tell it to use a specific node path? #259

Open unphased opened 2 months ago

unphased commented 2 months ago

Background:

I'm trying to set up typescript scripts as dependency-free scripts for macos and linux so I can move forward from shell scripts. Still love shell scripts, but sometimes it would be great to get javascript capabilities in the course of general scripting.

To facilitate this I use a shebang to a shell wrapper that will launch the program under tsx, the shebang wrapper script is as follows in case anyone is curious:

#!/usr/bin/env bash
echo Hello from tsx launcher in cwd "$(pwd)"
NODE_PATH=/opt/ts-global/node_modules:NODE_PATH exec npx tsx "$@"

As you can see, this defines a global store for npm dependencies. It all works, really well I might add.

The wrinkle now is with editing. Editing a plain typescript file in the absence of any of the usual typescript project files leads to tsserver throwing tons of errors for obvious reasons.

So, the natural approach is to put a basic tsconfig.json into the home directory. This seems to get picked up. However, it fails spectacularly (I tested with regular tsserver setup and with typescript-tools). It will recursively search my 600GB home dir and crash after a few minutes by running out of memory!

What I need to do for neovim, then, is since I'm already centralizing the "global" one off script dependency dir to /opt/ts-global/, I need to also configure NODE_PATH for the tsserver node process launched via Mason to point here, and possibly some other flags to convince it to look for tsconfig in this dir rather than try to pick it up where it usually looks.

I need to find a way to do this for typescript-tools.nvim because I rely on this implementation to obtain the move-to-file code action.

I looked at the readme and it shows how we can configure tsserver UserPreferences and FormatCodeSettings but presumably I want a way to manipulate CompilerOptions.

I think i will try to see if i can use paths or something in a ~/tsconfig.json though to have it point at this dir. that may work...

unphased commented 2 months ago

I might as well use this topic to log my exploration.

  1. failed after over an hour of searching to clearly understand what config i need to use to convince tsserver to perform logging or tracing. Nor how to send it in through mason through lspconfig into tsserver.
  2. therefore i went ahead to start doing surgery inside tsserver code itself...
  3. To prep for (2), I wrote a simple node debug helper shell script, which I installed in a location in my path. I named this shell script node, so that all node process launches would go through this wrapper, and this wrapper makes a call to /opt/homeberw/bin/node --inspect-brk=$PORT, I even made some machinery to auto increment the port, then chrome devtools could attach to any node process i want, including any of these LSP server implementations. From here I got where the tsserver code is, not that that required me to do all this to obtain that.
  4. I directly wrote an fs.appendFileSync based helper function that brute force logs into a special log file /tmp/tsserver_debug_slu.log inside the ginormous node_modules/typescript-language-server/lib/cli.mjs file under ~/.local/share/nvim/mason/packages/typescript-language-server.
  5. Confirmed this log file is being populated properly whenever I launch nvim and open a ts file now.
  6. I instrument the call to this.tsClient.start around line 22510 or so in cli.mjs and see it being called with:
251687,770944625 [
  'workspR',
  undefined,
  {
    trace: 0,
    typescriptVersion: TypeScriptVersion {
      source: 'bundled',
      path: '/Users/slu/.local/share/nvim/mason/packages/typescript-language-server/node_modules/typescript/lib/tsserver.js',
      logger: [PrefixingLogger],
      _api: [API]
    },
    logDirectoryProvider: LogDirectoryProvider { rootPath: undefined },
    logVerbosity: 0,
    disableAutomaticTypingAcquisition: undefined,
    maxTsServerMemory: undefined,
    npmLocation: undefined,
    locale: undefined,
    globalPlugins: [],
    pluginProbeLocations: [],
    onEvent: [Function: bound onTsEvent] AsyncFunction,
    onExit: [Function: onExit],
    useSyntaxServer: 2
  }
]
251687,772046000 [ 'start' ]

looks like i should be able at least to surgically force the logVerbosity up, check out if I need to fiddle with trace, etc...