feat: "deno.internalInspect" setting

[nayeemrmn]

Coupled with denoland/deno#21482.

[bartlomieju]

Sorry, I forgot to mention - maybe we need to actually provide an address for this setting? When I was using that inspector yesterday I was getting panics in the editor because previous LSP instance was already bound. WDYT?

[nayeemrmn]

Sorry, I forgot to mention - maybe we need to actually provide an address for this setting? When I was using that inspector yesterday I was getting panics in the editor because previous LSP instance was already bound. WDYT?

Isn't there some allocation for those addresses in the CLI? Like if you launch two inspected process at once:

[bartlomieju]

Sorry, I forgot to mention - maybe we need to actually provide an address for this setting? When I was using that inspector yesterday I was getting panics in the editor because previous LSP instance was already bound. WDYT?

Isn't there some allocation for those addresses in the CLI? Like if you launch two inspected process at once:

Nope - for regular deno run you can provide the address in --inspect flags, for the LSP for now I hardcoded the address to 127.0.0.1:10101. Maybe we should look for a random free port in the CLI? But that's a bit problematic because chrome://inspect needs an allowlist of ports it can connect to. So random port won't show up an inspector on the list.

[nayeemrmn]

But in the screenshot I provided they have automatically hosted themselves on different pathnames on the same host/port, and there's no error. Though only the first one seems to be listed on devtools.

[bartlomieju]

But in the screenshot I provided they have automatically hosted themselves on different pathnames on the same host/port, and there's no error. Though only the first one seems to be listed on devtools.

Oh I see what you mean. But if you have a Deno instance running with an inspector, then the LSP would try to bind to that port for inspector server. And that would still cause it to fail, because something is bound to that port.