Debug adapters should get the current open folder

[roblourens]

I think there used to be a 'cwd' property automatically sent over set to the current directory. Why was it removed? I'd like to make my launch config simpler by globbing for files inside the user's open folder.

[weinand]

@roblourens Initially we had a 'cwd' attribute as part of the protocol for 'launch' and 'attach'. But later we decided to remove all 'standard' attributes from the the 'launch' and 'attach' requests because they are highly debugger specific. So every debug adapter can introduce a 'cwd' in their package.json.

I suggest that you introduce a mandatory attribute 'cwd' and set its default value to ${workspaceRoot}. Add this to your default launch config as well.

[roblourens]

What do you mean 'highly debugger specific'? Seems like it would be applicable to any other client implementing the debug protocol. I'm trying to make the config simpler, but adding a mandatory property that should have the same value 100% of the time has the opposite effect.

[weinand]

@roblourens with 'highly debugger specific' I was referring to the whole set of attributes that we had initially. I agree, 'cwd' is probably one of the generic attributes.

My reluctance to introduce any 'side channel' attributes not visible to the user in his launch config, comes from my bad experience with any implicit, behind-the-scene magic: if I see a launch config, I see the whole picture. If you want to glob for files automatically, why not making this explicit?

I've seen many project folders with nested sub projects that had their own launch configs. Globbing at the root folder will probably not exclude the sub projects, which might be confusing. Having an explicit attribute where a user can specify from where to start the globbing seems to me a more transparent and flexible approach.

Do you consider to have an optional attribute where the user could override the default globbing behaviour?

[roblourens]

I agree in principle but it doesn't seem like magic to me because the user explicitly opened that folder. I would definitely allow them to override it for subprojects. I understand if you don't want to add it, at least specifying 'cwd' would still be simpler than figuring out 'webRoot' which is the property I want to get rid of.

[weinand]

@roblourens I'm not sure that I understand 'cwd' any better than 'webRoot' in the context of a web project. But you can use/introduce whatever you want.

What I don't understand is why you think that 'figuring out webRoot' is difficult? If a user is asked to create a new launch config, she will pick the Chrome Debug type and that will create launch configs that have the webRoot attribute already set to ${projectRoot}. So she does not even have to review the launch config but can just press F5. And if she later wants to narrow down the web root, the attribute is already there and she does not have to find (and understand) it first.

[roblourens]

In a really simple web project, you have some files that get built to root/out/script1.js and root/out/componentA/script2.js, referenced by your .html or whatever, and they're served as localhost/out/script1.js so webRoot is your project root, or a simple path from the root. In more complex configs, it's not uncommon for the url to not totally match the path on disk. Like your node_modules are served as one path, some scripts from another path, other scripts are bundled in memory and don't exist on disk. So I have a task to support a more complex webRoot config which can mirror the server config. But I can also make lots of cases "just work" by doing some fuzzy matching.

And then even in simple cases, I've found that some people are confused about what it should be set to, and I want to make it as simple as possible.

[roblourens]

@weinand @isidorn - It would be interesting to use #8645 to start the debug adapter with the workspaceRoot path via vscode.workspace.rootPath. This would let us eliminate cwd from the default launch config and simplify the launch config by a bit. Maybe we could go back to resolving a relative path for 'program' as well.

I probably wouldn't do this for webRoot like I said in June - like Andre said,

And if she later wants to narrow down the web root, the attribute is already there and she does not have to find (and understand) it first.

Changing the webRoot is somewhat common, and seeing the webRoot is necessary to understanding the behavior of chrome-debug. But I think that changing 'cwd' is more common, and people will already understand it if they need to change it.

Thoughts?

[isidorn]

If the extension contributes a startSessionCommand it can manipulate the launch.json as it sees fit, thus adding a vscode.workspace.rootPath would not be a problem.

[weinand]

@roblourens since we can manipulate the launch.json in the extension's startSessionCommand in any way we need, I think we can close this issue?