search

juanfranblanco / vscode-solidity

Visual Studio Code language support extension for Solidity smart contracts in Ethereum https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity
MIT License
885 stars 190 forks source link

Allow for multiple solc versions in separate folders #172

Open jjgonecrypto opened 4 years ago

jjgonecrypto commented 4 years ago

Related to @juanfranblanco's comment on https://github.com/juanfranblanco/vscode-solidity/issues/143

Let me understand the issue, so you have multiple folders (workspaces) and each one of them want to use a different version of solidity solc. At the moment the only way to override this, is to use a node package installation, but also this is always driven as well by the user settings.

This is actually a very interesting change, but yes there are many points of failure as we move from user settings, folder settings to workspace settings.

Ill do some research on this, but yeah a simple solution is that if you want to override a specific user setting you can use the npm package installation from the selected workspace folder.

Yes - we are in a situation where we are looking to support legacy contracts alongside modern contracts and need a way to have VSCode not complain like this:

image

Buidler supports multiple versions of solc, and this is a WIP branch: https://github.com/Synthetixio/synthetix/tree/adding-legacy-via-sources

I'm really looking to see if I can stop my IDE from flagging these legacy sources as errors.

juanfranblanco commented 4 years ago

@justinjmoses you can change the compiler version from your workspace using the settings and context menu.. image

this way your workspace will be validated and analysed using that version of solidity

jjgonecrypto commented 4 years ago

Right but I need two different versions within the one workspace...

juanfranblanco commented 4 years ago

The simplest solution is to open two instances of vscode each one with its own workspace settings. This way you can target specifically which version you want for each area. You are organising each version / legacy and area in folders correct? This way you can have different npm packages for dependencies?

pilagod commented 3 years ago

I happened to find out another workaround, you can turn off this setting in vscode:

“solidity.enabledAsYouTypeCompilationErrorCheck”: false

After that, vscode will not argue about the compiler version anymore. But this comes with a drawback that version specific syntax errors can only be found when you actually compile the files.

For instance, in version ^0.6.0, the constructor visibility needs to be specified. With this setting turning off, vscode won't remind you while editing code.

juanfranblanco commented 3 years ago

@pilagod yes, you will only get half of the functionality there. Much easier to open different folders. Another option, is to change the settings on the fly, using the context menu. Or as I do to work with optimism, mainly use a node setting configure to compile optimism, whilst working on latest all the time.

zemse commented 3 years ago

The simplest solution is to open two instances of vscode each one with its own workspace settings.

Workaround is fine, but it'd be super if it just pick the lowest version that satisfies the pragma and this behavior turned on using some flag in settings.json.

kryptoklob commented 1 year ago

Echoing that this is still kind of a pain - it's very common to need different solidity compiler versions, sometimes even three different versions, within the same project.

juanfranblanco commented 1 year ago

So now that we have mono-repo support, I guess this could be achieved by adding another settings file with this or read it from somewhere like foundry etc

kryptoklob commented 1 year ago

So now that we have mono-repo support, I guess this could be achieved by adding another settings file with this or read it from somewhere like foundry etc

Can you detail exactly how to do this? Can I just duplicate the settings file with different options?