Consider enabling `--external-sources` by default · Issue #883 · vscode-shellcheck/vscode-shellcheck · GitHub
Skip to content

Consider enabling --external-sources by default #883

Open

Description

@TrevorBurnham

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.

Thoughts?

Activity

  1. felipecrs commented on Jan 5, 2023

    @felipecrs
    Member

    Add external-sources=true to your .shellcheckrc. That's it.

  2. paescuj commented on Jan 5, 2023

    @paescuj

    @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?

  3. felipecrs commented on Jan 5, 2023

    @felipecrs
    Member

    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).

  4. paescuj commented on Jan 6, 2023

    @paescuj

    Thank you very much for your reply!

    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.

  5. felipecrs commented on Jan 6, 2023

    @felipecrs
    Member

    But I'm going to give that a shot 😃

    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?

  6. paescuj commented on Jan 6, 2023

    @paescuj

    Please do open the discussion there. I agree with you that this should be enabled by default, but on ShellCheck itself.

    Will do 👍

  7. felipecrs commented on Jan 6, 2023

    @felipecrs
    Member
  8. paescuj commented on Jan 6, 2023

    @paescuj

    PS: Bash IDE enables --external-sources by default:

    Okay, that's interesting 😃

  9. changed the title [-]SC1091 when using executing relative path[/-] [+]Consider enabling `--external-sources` by default[/+] on Feb 4, 2023
  10. felipecrs commented on Aug 27, 2023

    @felipecrs
    Member

    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:

    // .vscode/settings.json
    {
      "shellcheck.runArgs": []
    }

    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. :)

  11. the-moog commented on Sep 13, 2023

    @the-moog

    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?

  12. the-moog commented on Sep 13, 2023

    @the-moog

    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.

  13. felipecrs commented on Sep 13, 2023

    @felipecrs
    Member

    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.

  14. felipecrs commented on Sep 13, 2023

    @felipecrs
    Member

    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.

  15. felipecrs commented on Feb 9, 2024

    @felipecrs
    Member

    Fun fact, since husky v9 this is no longer applicable:

    The popular husky package for Node.js generates scripts that start like this:

    #!/usr/bin/env sh
    . "$(dirname -- "$0")/_/husky.sh"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions