vscode-r development workflow (WSL)

[ElianHugh]

Hey all,

I was hoping to get some input on how people are working on vscode-R contributions - I'm particularly interested if you use WSL!

One issue I've been having, is that the debug task (F5) for the extension has the arg "--disable-extensions". Now, it makes sense that this is the case, as you don't want other extensions to interfere with testing. However, this also means that the WSL extension is disabled! Up until now, I've been manually removing the argument during testing, and putting it back before pushing to the repo (which gets pretty tedious after a while). Has anyone run into the same issue, or had ways around it?

I'm not sure if this qualifies as an issue or not, so I'm starting here for now.

[renkun-ken]

We may create multiple launch profiles, one with all other extensions disabled (current), one vice versa.

[ElianHugh]

Sounds like a good idea - it looks like there's no way to enable specific extensions, so that's a no go. --useWSL used to be an option, but the remotes extension superseded that.

[renkun-ken]

I put a new launch item in 586a817.

[ManuelHentschel]

How about removing the .vscode/ folder entirely or moving its contents to e.g. example.vscode/?
I personally like to configure these files beyond just setting --disable-extensions, for example to set the opened folder when launching or changing the compile task to skip webpack.

Of course it's possible to have local changes that are not committed to github, but this can get quite annoying when switching between branches and lead to accidental commits to the github repo (as happened with "--disable-extensions", sorry about that one), so I think it would be easier for each developer to have their own config.

[Ikuyadeu]

.vscode/ will make develop to simple, and it will help develop, especially for new participants.
Also, if you have some useful settings, adding them is helpful for all of the collaborators.
At present, I think to disable/enable options can be worked by Renkun-kens' proposed task.json.

[ManuelHentschel]

Also, if you have some useful settings, adding them is helpful for all of the collaborators.

Some of the settings that are useful to me would not be useful for anyone else. E.g. I have a separate folder containing example files (usually just some simple test.R) which I use to test the feature I'm currently working on. This folder can be specified in launch.json so that the new vscode instance is always opened in this folder, which is quite useful for me.
Specifying a local path from my machine would just be annoying for anyone else though.

.vscode/ will make develop to simple, and it will help develop, especially for new participants.

IMO, this could be solved by moving the current contents of .vscode/ to e.g. example.vscode/, which new developers can simply rename in order to get started

[Ikuyadeu]

Sure, that a good idea and your motivation is essential.
But, I want to solve it by minimizing for making simple development workflow.
If you feel no trouble with extention, settings, tasks files. How is only make example.launch.json? Or making launch.json automatically by task.json if the developer does not have the file yet.

[ManuelHentschel]

I believe this is a topic with no "right" way to do it and I found a solution that works for me (https://avdi.codes/keep-local-modifications-in-git-tracked-files/), so I don't mind leaving the .vscode folder as it is. Thanks for your consideration though!

[ManuelHentschel]

On a similar note: how is the launch performance/delay for you when debugging the vscode-R extension from source? For me, there's always a noticeable delay, even when using webpack in watch mode. To solve this, I disabled webpack during development by changing the following lines in package.json

"main": "./out/extension",
"scripts": {
  "watch": "tsc --watch -p ."
}

and in the launch.json:

"preLaunchTask": "npm: watch"

With these changes, the Extension Development Host window opens pretty much instantaneously (apart from the very first time after starting vscode).

If other people experience the same delay (and the fix works for them), we could consider adjusting the deployment process to only use webpack before publishing.

[ElianHugh]

This is monumentally faster for me!