[Bug?]: yarn config get / unset throws Usage Error when a setting isn't in the config

[michaelfaith]

Self-service

• I'd be willing to implement a fix

Describe the bug

Whenever you use the yarn config unset <settingName> or yarn config get <settingName> command, with a setting name that isn't present in the config, it throws a Usage Error: Couldn't find a configuration settings named <settingName>. This can be problematic when used in a CI/CD context. For example, we have reusable pipeline templates that service multiple projects. Some of those projects use the afterInstall plugin and so those config files have afterInstall settings applied. When bumping versions in our pipeline, we don't want the afterInstall scripts to run. So we have code that unsets the afterInstall setting and re-sets it at the end of the stage. Blindly unsetting that property would be ideal, but since that throws an Error, I tried using the config get command to see if that setting is present before unsetting, but even that throws an error.

It seems like the behavior for both calls should be a no-op. CLI's like git will just return an empty string if you try and get a config prop that isn't there. It doesn't error out (e.g. git config --get user.phone). Similarly, if you're trying to unset a prop that isn't there, I would expect it to just do nothing, not throw an error.

I wasn't sure if this should be considered a Bug or an Enhancement, so if it needs to be re-labled/re-titled, that's totally cool.

To reproduce

Run yarn config unset afterInstall or yarn config get afterInstall on a project that doesn't have afterInstall set.

Environment

System:
    OS: Windows 10 10.0.22621
    CPU: (12) x64 11th Gen Intel(R) Core(TM) i5-11500H @ 2.90GHz
  Binaries:
    Node: 16.19.0 - ~\AppData\Local\Temp\xfs-de411936\node.CMD
    Yarn: 3.5.1 - ~\AppData\Local\Temp\xfs-de411936\yarn.CMD
    npm: 8.19.3 - C:\Program Files\nodejs\npm.CMD

Additional context

[arcanis]

It seems like the behavior for both calls should be a no-op. CLI's like git will just return an empty string if you try and get a config prop that isn't there. It doesn't error out (e.g. git config --get user.phone). Similarly, if you're trying to unset a prop that isn't there, I would expect it to just do nothing, not throw an error.

On the other hand, it's generally seen a good practice in Bash to enable nounset to avoid accidentally using bad variable names by mistake. Given that Yarn settings are fairly susceptible to typos, I'd tend to prefer our behaviour - which you can easily opt-out by adding || true to your calls 🤔

[michaelfaith]

I guess, to me, unsetting and getting configuration props that don't exist on the cli doesn't come with it the same downsides / repercussions that attempting to reference a variable that doesn't exist in a script might have (especially in the CI/CD pipeline use case). And in our case, which is probably not the norm, our build servers are Windows agents running Powershell tasks. It just doesn't feel like getting a config prop that hasn't been set is an erroneous action. Otherwise, how would you check if the config has any property that you might want to change template behavior for in a cli context?

[arcanis]

Otherwise, how would you check if the config has any property that you might want to change template behavior for in a cli context?

I guess something like this? A little verbose, and perhaps the >& /dev/null could be turned into a --check option 🤔

if yarn config get someSetting > /dev/null; then
  yarn config set someSetting hello-world
fi

Alternatively, I'd probably be fine to have a yarn config set --tolerate-unknown flag that would silence the error.

[michaelfaith]

Right on. Yeah, there are definitely more verbose workarounds; so it's not a blocker. It just seems like there should be a built-in way to relax that call so it's not throwing errors if the presence of the prop is uncertain (like in the case of large-scale pipelines servicing several projects with varying configs).

[yarnbot]

Hi! 👋

It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.

[michaelfaith]

@arcanis should this stay open based on your recommendation (some kind of tolerate option)?

[yarnbot]

Hi! 👋

It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.

[michaelfaith]

@arcanis should this stay open based on your recommendation (some kind of tolerate option)?

[arcanis]

It's not my priority and it seems "easy", so if someone wants to implement it that's fine by me - but if noone does for three+ months, it seems reasonable to let it close.

[michaelfaith]

Fair enough. I'd like to help with this, but just haven't had the time. If it closes, and i do get a chance to learn the codebase enough to help with this at some point, is there a way to re-open it?

[yarnbot]

Hi! 👋

It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.