-
-
Notifications
You must be signed in to change notification settings - Fork 22
Description
Clear and concise description of the problem
Tools that use package-manager-detector to resolve commands often need to respect package manager configuration settings. Currently, there's no way to detect and apply these settings when executing commands.
Real-world examples:
pncat doesn't respect saveExact setting - even when saveExact: true is configured, pncat add uses caret ranges instead of exact versions. Tools need to manually check for configuration files and map them to CLI flags. Inconsistent behaviour across different environments and projects
Suggested solution
Enhance the existing resolveCommand function to optionally include configuration-derived flags:
// Current behaviour
const { command, args } = resolveCommand('pnpm', 'add', ['@antfu/ni'])
// Returns: { command: 'pnpm', args: ['add', '@antfu/ni'] }
// Proposed enhancement
const { command, args, configArgs } = resolveCommand('pnpm', 'add', ['@antfu/ni'], { includeConfigFlags: true })
// Returns: {
// command: 'pnpm',
// args: ['add', 'lodash'],
// configArgs: ['--save-exact'] // when save-exact=true is detected
// }The feature would detect configuration through programmatic usage of the config commands supported by npm, pnpm, and yarn (deno and bun do not seem to natively support this at this time).
Alternative
-
Include config arguments directly in the existing
args, but this felt like a change that would affect configs purely using the tool for CLI text display, or configs that specifically wanted to override the existing behaviours. -
Creating package-manager-specific config detection functions (e.g., getPnpmConfig()), but the resolveCommand enhancement felt more consistent with the library's existing patterns and would benefit all package managers equally.
-
Do nothing. Not all packages need this behaviour, and it could be complicated to parse and maintain the configurations for different package managers.
Additional context
I'd originally suggested this in the pncat repository, but it was rightly pointed out that this could be complicated to maintain. Not to push the burden of maintenance elsewhere, but, it seemed like a better fit for a package like this to maintain (if it's not out of scope), as it would allow any other tool using package-manage-detector to correctly implement commands where necessary.
I would be willing to PR the groundworks for a feature like this, although I would need help discovering all the different config options that would be accessible for each command.
Validations
- Follow our Code of Conduct
- Read the Contributing Guide.
- Check that there isn't already an issue that request the same feature to avoid creating a duplicate.