You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue might not be sent to the right place since the LSP server is only consuming what other tools report. It's the first line of usage that leads me to want this feature though.
Still, I'm a bit uncertain where this should get reported since I don't think there is some manner of static analysis for puppet DSL in any tool and it doesn't seem like it would fit in the context of a linting tool like puppet-lint. Maybe puppet parser validate should be the place where this happens? I'm also not sure about this.
Please do advise if you think the issue should rather be reported elsewhere
Use Case
I use puppet-language-server with nvim through an LSP plugin (coc.nvim) and I very much like the feedback that I'm getting while editing.
One thing that I can see happening though is that if I assign the wrong type to something, I won't get told. For example the following snippet would say nothing through the LSP even though it's obviously wrong:
classblah (
Boolean $moo = "nope, this is a string",
) {
notice("just filling up the class with something")
}
In a similar manner, if in another file I include that class with the wrong type for a parameter, I'll only learn about this error at runtime:
class { 'blah':
moo => [1, 2, 3, 4, 5],
}
Describe the Solution You Would Like
It would be nice if we could get feedback about those types of cases directly in the editor.
The first case would be relatively trivial for puppet parser validate to verify, but the second one would imply that it could find the right class or defined type in the modulepath to then report about the wrong type for params.
Do you think that puppet parser validate would be the right place to request such a feature? or do you think something else would rather be a better destination? Once the type of error gets reported, this LSP will show it to users without much effort I'm guessing.
The text was updated successfully, but these errors were encountered:
Apologies for delayed response. I love the first idea and we will look to review when we could prioritize a linter. The second looks a little more complicated in terms of what we have in the tooling today.
My ruby skills are very minimal and also I'm not inclined to sign the CLA required to get stuff into projects steered by Puppet Inc. So I'm probably not going to contribute patches.
But I could help out with anything else like just trying to figure out where we should change things, testing patches, etc.
I'm not present on Slack but I tend to idle in the IRC channel with the same username as my github accout. Don't hesitate to reach out to me there if you'd like us to exchange more rapidly than through here.
This issue might not be sent to the right place since the LSP server is only consuming what other tools report. It's the first line of usage that leads me to want this feature though.
Still, I'm a bit uncertain where this should get reported since I don't think there is some manner of static analysis for puppet DSL in any tool and it doesn't seem like it would fit in the context of a linting tool like puppet-lint. Maybe
puppet parser validate
should be the place where this happens? I'm also not sure about this.Please do advise if you think the issue should rather be reported elsewhere
Use Case
I use puppet-language-server with nvim through an LSP plugin (coc.nvim) and I very much like the feedback that I'm getting while editing.
One thing that I can see happening though is that if I assign the wrong type to something, I won't get told. For example the following snippet would say nothing through the LSP even though it's obviously wrong:
In a similar manner, if in another file I include that class with the wrong type for a parameter, I'll only learn about this error at runtime:
Describe the Solution You Would Like
It would be nice if we could get feedback about those types of cases directly in the editor.
The first case would be relatively trivial for
puppet parser validate
to verify, but the second one would imply that it could find the right class or defined type in the modulepath to then report about the wrong type for params.Do you think that
puppet parser validate
would be the right place to request such a feature? or do you think something else would rather be a better destination? Once the type of error gets reported, this LSP will show it to users without much effort I'm guessing.The text was updated successfully, but these errors were encountered: