Skip to content

fix: --flags-dir now works on third-party plugins @W-21178947@#1549

Closed
jfeingold35 wants to merge 4 commits intomainfrom
d/W-21178947
Closed

fix: --flags-dir now works on third-party plugins @W-21178947@#1549
jfeingold35 wants to merge 4 commits intomainfrom
d/W-21178947

Conversation

@jfeingold35
Copy link
Copy Markdown
Contributor

This fixes SF CLI Issue #3493.

In theory, SF CLI commands are supposed to support a --flags-dir flag that supplies a directory containing files denoting all of the other flag values. i.e., instead of sf hello --flag1 a --flag2 b .... --flag50 beep, you could put all of those flags in a file and do sf hello --flags-dir myflags. This feature works as designed for first-party plugins. However, when a third-party plugin is using the same version of @oclif/core as the CLI on which it's running, --flags-dir doesn't work.

The problem was that the results of the preparse hook (which handles --flags-dir) were being compared to a cached version of the plugin, as seen here. The cache was only being populated with that value when the config loaded, as seen here, and since the versions of OCLIF were the same, that reloading wasn't occurring for the Command-level plugin. It worked for first-party plugins because they import OCLIF from the same location as the CLI and thus use the same cache directly instead of using a different cache populated with overlapping values.

The fix is to simply reload the config all the time instead of only when the versions mismatch. This was an optimization that was necessary once upon a time, but is no longer necessary because of how plugin instantiation has been optimized elsewhere.

Comment thread src/config/config.ts

return opts
debug(`reloading config from ${opts._base} to ${BASE}`)
const pluginMap: Map<string, IPlugin> = new Map(opts.getPluginsList().map((p) => [p.name, p]))
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change was required to fix the external tests for plugin-plugins, which work by stubbing out getPluginsList to return a desired list.
In the wild, getPluginsList() works by iterating over .plugins anyway, so there's no actual functional difference.

@jfeingold35
Copy link
Copy Markdown
Contributor Author

I did a git rebase which seems to have mangled this PR, and I don't feel like manually repairing it, so I just recreated the functional changes on a new PR, #1553 .

@jfeingold35 jfeingold35 closed this Mar 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Using --flags-dir on (third-party) sf plugins does not work

1 participant