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
{{ message }}
Repository navigation
Consider enabling --external-sources by default #883
The popular husky package for Node.js generates scripts that start like this:
#!/usr/bin/env sh."$(dirname -- "$0")/_/husky.sh"
The vscode-shellcheck extension complains about the second line:
Not following: ./_/husky.sh was not specified as input (see shellcheck -x). shellcheck (SC1091)
(The warning is emitted whether or not I enable the "Shellcheck: Use Workspace Root As Cwd" setting.)
I raised this issue with the husky folks (typicode/husky#1226) to see if there might be a better way to write the script, and they suggested that it might be better for vscode-shellcheck to change its behavior instead, by flipping on Shellcheck's --external-sources flag.
@felipecrs
Yeah, but I wonder whether anything speaks against having this enabled by default?
I can imagine that a lot of users of this extension are running into the warning mentioned above...
Can we please have a discussion on this?
I see, so your point is to have --external-sources enabled by default.
My opinion is: this should be discussed in ShellCheck.
The VS Code extension should follow the CLI behavior as closely as possible, so that they return similar results. Therefore, if you someday run shellcheck from CLI for whatever reason (like automated linting in your CI), you will receive the same error and you need to act on it (create the .shellcheckrc file).
I see, so your point is to have --external-sources enabled by default.
Exactly, that was my intention.
My opinion is: this should be discussed in ShellCheck.
The VS Code extension should follow the CLI behavior as closely as possible, so that they return similar results. Therefore, if you someday run shellcheck from CLI for whatever reason (like automated linting in your CI), you will receive the same error and you need to act on it (create the .shellcheckrc file).
You've made a very valid point! However, I'm not so sure whether ShellCheck is interested in enabling this option by default... But I'm going to give that a shot 😃
I'd still like to emphasize that I think the context of this extension is usually a bit different than with the native command.
By this I mean that it is natural to specify a single file when executing the command, while the extension is sort of being executed against an entire (VS Code) project and not really targeting a single file.
PS: If we enable it by default, we can probably add it to the default shellcheck.runArgs. Users who dislike this, could opt-out by adding to their configuration:
According to ShellCheck Wiki for SC1091 we should be able to use # shellcheck source=<filepath> I tried this and it did not work. Is that relevant to this issue?
I would argue that in VScode, in a project with more than one dev, we should not use .shellcheckrc as that make the dev environment non-portable and possibly different between users. Once another dev checks out the code, they may not have the same RC file. They could then make changes to 'fix' issues that are not an issue, e.g. path to sourced file.
I was talking about having the shellcheckrc file in your git repository. Are you talking about the same thing? I suspect you are talking about having a shellcheckrc file in your home folder, which is certainly not what I recommend.
According to ShellCheck Wiki for SC1091 we should be able to use # shellcheck source=<filepath> I tried this and it did not work. Is that relevant to this issue?
It should work the same as the CLI. Just be aware of how cwd works in the vscode extension, which you can change through the extension settings.
Activity
felipecrs commentedon Jan 5, 2023
Add
external-sources=trueto your.shellcheckrc. That's it.paescuj commentedon Jan 5, 2023
@felipecrs
Yeah, but I wonder whether anything speaks against having this enabled by default?
I can imagine that a lot of users of this extension are running into the warning mentioned above...
Can we please have a discussion on this?
felipecrs commentedon Jan 5, 2023
I see, so your point is to have
--external-sourcesenabled by default.My opinion is: this should be discussed in ShellCheck.
The VS Code extension should follow the CLI behavior as closely as possible, so that they return similar results. Therefore, if you someday run shellcheck from CLI for whatever reason (like automated linting in your CI), you will receive the same error and you need to act on it (create the
.shellcheckrcfile).paescuj commentedon Jan 6, 2023
Thank you very much for your reply!
Exactly, that was my intention.
You've made a very valid point! However, I'm not so sure whether ShellCheck is interested in enabling this option by default... But I'm going to give that a shot 😃
I'd still like to emphasize that I think the context of this extension is usually a bit different than with the native command.
By this I mean that it is natural to specify a single file when executing the command, while the extension is sort of being executed against an entire (VS Code) project and not really targeting a single file.
felipecrs commentedon Jan 6, 2023
Please do open the discussion there. I agree with you that this should be enabled by default, but on ShellCheck itself.
About enabling here by default, @timonwong do you have any opinion about it?
paescuj commentedon Jan 6, 2023
Will do 👍
felipecrs commentedon Jan 6, 2023
PS: Bash IDE enables
--external-sourcesby default:// Additional ShellCheck arguments. Note that we already add the following arguments: --shell, --format, --external-sources."
paescuj commentedon Jan 6, 2023
Okay, that's interesting 😃
[-]SC1091 when using executing relative path[/-][+]Consider enabling `--external-sources` by default[/+]felipecrs commentedon Aug 27, 2023
PS: If we enable it by default, we can probably add it to the default
shellcheck.runArgs. Users who dislike this, could opt-out by adding to their configuration:I believe the majority of the users would prefer this feature, and for the minority who doesn't, they can opt-out like above.
This should give a better out of the box experience after all.
Anyone interested to send a PR?
Worst case: we revert. :)
the-moog commentedon Sep 13, 2023
According to ShellCheck Wiki for SC1091 we should be able to use
# shellcheck source=<filepath>I tried this and it did not work. Is that relevant to this issue?the-moog commentedon Sep 13, 2023
I would argue that in VScode, in a project with more than one dev, we should not use
.shellcheckrcas that make the dev environment non-portable and possibly different between users. Once another dev checks out the code, they may not have the same RC file. They could then make changes to 'fix' issues that are not an issue, e.g. path to sourced file.felipecrs commentedon Sep 13, 2023
I was talking about having the shellcheckrc file in your git repository. Are you talking about the same thing? I suspect you are talking about having a shellcheckrc file in your home folder, which is certainly not what I recommend.
felipecrs commentedon Sep 13, 2023
It should work the same as the CLI. Just be aware of how cwd works in the vscode extension, which you can change through the extension settings.
felipecrs commentedon Feb 9, 2024
Fun fact, since husky v9 this is no longer applicable: