Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Allow to set the path for the plugins #206

Open
juanfranblanco opened this issue Apr 1, 2020 · 24 comments
Open

Feature request: Allow to set the path for the plugins #206

juanfranblanco opened this issue Apr 1, 2020 · 24 comments
Milestone

Comments

@juanfranblanco
Copy link

Hi I hope you are all well,

Vscode is not able to load the plugins as these will not be packaged with the extension, to workaround this it will be ideal if a path could be passed to load the plugins together with the list of names.

const plugins = require(`solhint-plugin-${pluginName}`)

This is how it is handled in prettier.

Suggestion: The solhint.json file could include a path or allow to set this by the ide by setting the path to be the same as the current project node_modules.

Reference: juanfranblanco/vscode-solidity#169

@fvictorio
Copy link
Contributor

Hi @juanfranblanco, sorry for not responding before. I'm not 100% sure I understand what would work for you. In the linked issue you suggest having a flag similar to prettier's --plugin-search-dir, is that correct? If we implement that, would that solve the issue for you?

@juanfranblanco
Copy link
Author

juanfranblanco commented Apr 3, 2020

Don't worry, responding issues is really hard and takes time.

You are right that is how it works with prettier. So the extension could do the usual magic of letting the user set it on the solhint file, in the extension user settings or if nothing is set, use the the default node_modules in the workspace.

This is how I have integrated with prettier if it helps:
https://github.com/juanfranblanco/vscode-solidity/blob/master/src/formatter/prettierFormatter.ts#L17-L18

@fvictorio
Copy link
Contributor

I see, makes sense. Will try that approach then, thanks 👍

I guess you are using solhint as an executable binary, right? In version 3.0 we tried to also properly export it as a "library", so maybe you want to try this. That's not documented yet, but it's just:

const { processStr } = require('solhint')

processStr(source, config, filename)

Both config and filename are optional. In this case, I guess you'd pass the pluginSearchDirs options there.

@fvictorio
Copy link
Contributor

Oh, and we should document what is returned by that function 🤦‍♂️ I'll try to do it when I have some time, but for the time being you can probably figure it out by inspecting it 😅 Let me know if you have any questions about that.

@juanfranblanco
Copy link
Author

juanfranblanco commented Apr 3, 2020

Solium is used as follows: https://github.com/juanfranblanco/vscode-solidity/blob/master/src/linter/solium.ts it was contributed by yourselves :). So all the integration is done internally.

@fvictorio
Copy link
Contributor

This is solhint, not solium 😄

@juanfranblanco
Copy link
Author

Oh my!! Sorry :)

@juanfranblanco
Copy link
Author

@fvictorio it seems that we are having issues with extends too [solhint:recommended] will this be related, it used to work before.

@Jaime-Iglesias
Copy link

Any update on this issue ? I'd love to see custom plugins and the recommended rule set working on the extension :D

friendly ping @fvictorio

@fvictorio
Copy link
Contributor

Not yet, hopefully this week.

@fvictorio
Copy link
Contributor

Hey @juanfranblanco, could you try installing Solhint from github, using the plugin-search-dir branch, and see if this works for you?

You should call it like this:

processStr(solidityCode, config, {
  pluginSearchDir: '/path/to/dir'
})

Where solidityCode is a string with the code to lint, config is an object like the one in .solhint.json, and pluginSearchDir is the path to where the node_modules directory with the plugins is located. That means that you should use /path/to/plugins, not /path/to/plugins/node_modules.

@fvictorio
Copy link
Contributor

I just did the same change for shareable configs (aka extends) too. Same branch, so you should be able to test it.

Of course, that means that pluginSearchDir is a bad name, I will think of something better (extensionsDir?), but first I want to see if it works 😄

@fvictorio fvictorio added the 3.0 label Apr 23, 2020
@Jaime-Iglesias
Copy link

@juanfranblanco friendly ping

@juanfranblanco
Copy link
Author

@Jaime-Iglesias sorry a bit overboard at the moment, next week i will have some time for this ;)

@Jaime-Iglesias
Copy link

@Jaime-Iglesias sorry a bit overboard at the moment, next week i will have some time for this ;)

Yeah, don't worry - just wanted to make sure you had seen it - Stay safe !

@fvictorio fvictorio removed the 3.0 label May 4, 2020
@fvictorio fvictorio added this to the 3.1.0 milestone May 4, 2020
@fvictorio
Copy link
Contributor

Hey @juanfranblanco, did you have a chance to test this?

@juanfranblanco
Copy link
Author

@fvictorio no I have not had time.. did you included it in the current 3.0.0 release?

@fvictorio
Copy link
Contributor

No, it's a little risky so I wanted to validate it first.

I don't use VSCode, but how hard is for me to test it myself? I guess I would need to clone your extension, add this change, and load it locally in the editor. Is that correct?

@juanfranblanco
Copy link
Author

yeah.. just clone the extension and run it :) now obviously you need to reference your package to test the change, it will be great if you could do it as you know best what to expect and how to use that package. If you need any help to get setup let me know.

@Jaime-Iglesias
Copy link

Hi all!

Has there been any progress regarding this issue ?

@fvictorio
Copy link
Contributor

@Jaime-Iglesias I'm working on it, I hope to have it fixed on these days!

@juanfranblanco I started looking into this but I ran into an issue. I don't know anything about developing vscode extensions, so I might be asking very silly questions.

I edited solhint.ts to receive a extensionPath: string in the constructor, so that that can be used when calling linter.processStr. The problem is, SolhintService is instantiated in server.ts and that file doesn't have access to context.extensionPath. This doesn't happen with formatDocument, that is used in extension.ts and has access to that context. Could you give me a pointer here?

This is the branch I'm working on: fvictorio/vscode-solidity@53d8f4c Of course, for that to work you have to link solhint in the plugin-search-dir branch.

@Jaime-Iglesias
Copy link

Hi all - hope everyone is doing well!

Has there been any progress on this ?

@fvictorio
Copy link
Contributor

Hey @Jaime-Iglesias, not from me, I got stuck with what I mentioned in my last comment and haven't really worked on this since then, and I don't really know when I'll have time to do it 🙁

@Jaime-Iglesias
Copy link

Hey @Jaime-Iglesias, not from me, I got stuck with what I mentioned in my last comment and haven't really worked on this since then, and I don't really know when I'll have time to do it

No worries - I think I'll endup just ditching the solidity extension completely and switch to a different approach, solhint is too useful to let go :D

Totally unrelated, just subscribed to your "exploring Ethereum", keep it up !

lhemerly added a commit to lhemerly/solhint that referenced this issue Mar 24, 2023
Change loadPlugin function at index.js to receive the plugin path.
dbale-altoros added a commit that referenced this issue Jul 6, 2023
ISSUE #206 - Plugins can be in any path
dbale-altoros added a commit that referenced this issue Jul 28, 2023
Revert "ISSUE #206 - Plugins can be in any path"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants