Consider changing the name of the defaultCompiler settings, as well as some of its values

[aathan]

The words "remote" and "local" in the context of vscode projects frequently refer to the location of the workspace relative to the location of vscode itself.

The words "remote" and "local" in the context of this solidity extension's defaultCompiler setting seems to instead refer to how the compiler is provided to the extension, and "local" does not mean "local to vscode itself" it means "local to where the workspace is" ... which can be "remote" to where vscode itself is.

The reason "remote" and "local" for these values is confusing is that it's possible to imagine that selecting "local" means that the extension will somehow use a compiler located on the machine providing the vscode UX rather than on the machine that hosts the workspace. Instead, "local" simply means that the extension won't go download a compiler but will instead look for it where specified by the compileUsingLocalVersion setting.

Perhaps better terminology would be "managed" (to replace "remote") and "existing" (to replace "local").

Similarly, "defaultCompiler" is misleading given that there is a setting called compileUsingLocalVersion which is an imperative that implies that if this is set, the specified local version will be used instead of the "defaultCompiler". But that's not what it does at all. That setting actually means something closer to pathOfCompilerJs (i.e., the location of the solc js file that provides the compiler). etc.

I suggest changing "defaultCompiler" to "compilerLocatorMode" because in fact, it can't be overridden at the settings level. As far as I can tell, the only "override" that might happen would be during the specific compilations done via the vscode UX (e.g., by executing "Solidity: Compile with configured Remote version")

Better naming conventions for these settings would reduce the confusion about how all of the extension's setting interact with each other, especially when trying to resolve other problems simultaneously (like the import remapping settings etc).

I'm posting this issue mostly to help anyone else that has been trying to figure out how the settings interact.

[juanfranblanco]

Remote means that solcjs will be downloaded from the server, local means that a local solcjs will be used. Thanks for your suggestions but changing this settings will affect to many users, so that will be an inconvenience. The readme and settings explains what these means.

[aathan]

@juanfranblanco I am giving feedback that as a new user these labels were nevertheless confusing. Again, "Compile using a local solc binary file" leaves the question open as to what "local" means.

I completely understand if changing these would be too big of a breaking change. In that case, I would suggest you at least update the explanatory text to say something like "Compile using a solc binary file you provide, at the location specified by this setting, accessible from the location of the vscode workspace" (otherwise "local" can be interpreted to mean where vscode is running, vs where the workspace is).

Likewise, the "remote version" description could read "Compile using a solc binary that is downloaded for you by this extension from the public solc repository based on the version string you provide in this setting. Use the command 'Solidity: Get solidity releases' ...." because otherwise a user can think "is this extension finding all the solc versions available on the remote ssh host that has my workspace?"

Many projects download solc (foundry, hardhat, etc) so this is a reasonable thing to think.

[juanfranblanco]

The local path it is expected to be an absolute path, not relative to the local workspace, hence the example. Does the Readme not help? https://github.com/juanfranblanco/vscode-solidity#using-a-different-version-of-the-solidity-compiler Maybe on the settings more info could be added. @aathan

[aathan]

... yes the readme was helpful. Thank you for writing it :)

In my comment, I didn't mean "relative" in terms of the path, I meant relative in terms of the physical host of the workspace. That's why the text I suggested doesn't use the words "local" or "relative" in that text:

"Compile using a solc binary file you provide, at the location specified by this setting, accessible from the location of the vscode workspace"

The reality is that interactions with vscode extensions frequently do not start at the readme. Instead it's not uncommon for people to immediately go to settings etc and see if there is an obvious change that can happen to fix some syntax highlighting problem etc. It's the usual "RTFM" issue. That's why I was suggesting some better text there, and/or changes to the setting names themselves. If you do eventually decide to make changes to these names, you could make them backwards compatible for a while.

All the best, and thanks for a nice extension!

[juanfranblanco]

@aathan Thanks for the feedback, I'll try to add most of the info from the readme to the settings. I'll check if links can be added to expand it.

[aathan]

Thanks Juan. On a related note, it may be good to mention (in the readme and/or config prompts) that the paths are not meant to point directly to solc executables, but rather, to their "js bundles" of whatever type those are...