Need to be able to run the standalone typespec version from the IDE

[timotheeguerin]

This is a bit of an issue with using the standalone exe right now, the language server still needs to run from node.

The simplest options is probably to try to use the node version provided by vscode as fallback. This used to not work as it was too old and didn't support ESM modules but it is probably updated now.

The alternative is to add a flag to the standalone cli like --server that load the local LSP code.

[markcowl]

@RodgeFu FYI, need some cooradination on how to solve this for IDE

[RodgeFu]

May I have more background abuot the issue? Do you mean we will have standalone typespec which can work without node installed on the machine? thx

[timotheeguerin]

Yes, except we already have it, it is just not documented and advertised yet as there is some uncertainty to resolve with the package manager first(tsp install).

[RodgeFu]

I see. In this case, I would prefer the option to add --server in the standalone cli, so that the solution can also work with other IDEs like Visual Studio. thanks.

[timotheeguerin]

Thats a great point, I'll work on adding that to the CLI

[RodgeFu]

Can we also add --server to the normal cli so that IDE can just call tsp --server to start the server no matter it's standalone or not? Otherwise IDE needs to have a way to figure out whether it's standalone or from 'npm install -g ...' to determine whether to call tsp --server or tsp-server? thanks.

[timotheeguerin]

IDE will need to as the tsp cli is not necessary installed globally in the node mode

[RodgeFu]

Do we have a way to check whether the standalone cli is installed on the machine or not so that IDE can check?

[timotheeguerin]

As part of the --server pr I also updated the --version to include standalone in the version in the case it is the standalone version. (open to a better name as well)

[RodgeFu]

I mean how IDE can know that a standalone CLI has been installed on the machine so that it will try to start server by tsp --server? i.e. by checking some env variable, path, registry...

[timotheeguerin]

It will be installed in the path so you can run which tsp and/or tsp --version

[RodgeFu]

I see. But starting a command to do the check will make it slower to start our extension which I feel is already a little slow now. Now the server resolving logic are using tsp-server as the last fallback solution and just try to use it and report error if needed. So if we can also have --server for the normal cli, we can just change the last fallback solution to tsp --server which will be able to work no matter user has standalone or global cli without the side effect in perf.

[timotheeguerin]

The standalone cli will not contain the compiler logic because running the global compiler makes 0 sense(same as running the global tsp-server, past just doing basic highlighting)

The goal of the global cli is to provide access to the tsp command tsp init and tsp install everything else is done by loading the local version.

If you have a better idea to detect, open to new idea.

[RodgeFu]

Looked at the PR and it seems we are having different understanding in the --server argument. From the current implementation in PR, we need to use it like tsp --server {path to some installed tsp-server.js}. But

• if i already have tsp-server.js installed somewhere else on the machine, it would mean I had had nodejs installed on the machine, so i don't need standalone tsp to start it for me.
• if I only have standalone cli installed, then i need to figure out the tsp-server.js installed by standalone cli itself somehow (or is tsp-server installed in standalone mode?), and then send the tsp-server.js path back to it again to trigger it which feels unnecessary at all.

So in my option, the --server is all the argument needed to indicate the tsp to start as server mode. no extra info needed. When people run tsp --server, the cli will just run the tsp-server.js in it which is clean and straightforward.

btw, is there any doc about how to use the standalone typespec? do i just need to run the install.ps1 and everything should work?

[timotheeguerin]

if i already have tsp-server.js installed somewhere else on the machine, it would mean I had had nodejs installed on the machine, so i don't need standalone tsp to start it for me.

thats not true, the standlaone cli would have installed it, it also comes with tsp install, how else do you think you can use typespec?

It's just javascript code how it was installed(which package manager) is irrevent to the typespec engine, it MUST just be installed locally to work correctly. Global install of the tsp server or the compiler is broken and should not be used(we have an issue to make it an error if you try to build from the global install without haveing it installed so it doesn't fail later with confusing errors)

btw, is there any doc about how to use the standalone typespec? do i just need to run the install.ps1 and everything should work?

yes(in pr #5907) and yes

[RodgeFu]

what do you mean by "Global install of the tsp server or the compiler is broken and should not be used"? When will it happen? it will break the "Create TypeSpec Project" scenario in vscode when user has nothing installed on the machine and depends on global compiler to do the init... , people dont have local tsp-server in that case

[timotheeguerin]

Sorry I mean just the compile part the rest make sense to be able to run globally(and that what the standalone cli purpose is as well)

i.e. running tsp compile . in a folder that doesn't have the compiler installed will fail as it already does but later because it cannot load the libraries (as they are most likely not installed if the compiler is not)

[RodgeFu]

Thanks for the clarification. So try to summarize what I get:

1. the standalone cli will provide tsp init, tsp install, tsp --server {tsp-server.js}
2. the global cli will work as before (including tsp-server) except not supporting tsp compile anymore
3. standalone tsp install can be used to install local compiler when nodejs is not available on the machine (will we support tsp install {package?)
4. standalone tsp --server can be used to start local tsp-server when nodejs is not available on the machine
5. tsp --version can be used to check whether standalone tsp is installed (when its version contains 'standalone')

So from IDE, when loading lsp, we will

1. use tsp --version to check whether standalone tsp available (change needed)
2. try to find tsp-server.js from user settings or local node_module folder
3. if found
   3.1. use tsp --server tsp-server.js if standalone tsp available (change needed)
   3.2. use node ... if standalone tsp not available
4. if not found
   4.1 fallback to default tsp-server command

For "Create TypeSpec Project":
I want to bundle these init logic from compiler more now... will see whether I have time to look into that base on you pr before ga...

[timotheeguerin]

plan looks good, just another clarification on teh assumptions

tsp compile . 

where tsp is the standalone cli or the global install will keep working as long as you run this in a folder that does have the compiler installed(First thing it does when you start the cli is lookup for the local compiler/cli and run that one instead)