Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rush] Allow global configuration of package manager settings that Rush passes during install #1994

Open
1 of 2 tasks
D4N14L opened this issue Jul 4, 2020 · 0 comments
Open
1 of 2 tasks
Labels
general discussion Not a bug or enhancement, just a discussion needs design The next step is for someone to propose the details of an approach for solving the problem

Comments

@D4N14L
Copy link
Member

D4N14L commented Jul 4, 2020

Is this a feature or a bug?

  • Feature
  • Bug

Please describe the actual behavior.

There are some settings/features that package managers provide that users may want to set every time they run an install. A good example of this would be network timeout settings, which

  • vary on availability depending on the package manager used (ex. fetch-retry-factor in PNPM, or network-timeout in Yarn)
  • need to be passed in every time the install/update command is run

Currently, Rush does not support passing in any package manager specific values that aren't explicitly supported on the rush install/rush update CLI, or specified in rush.json package manager options. This is limiting because

  • the CLI arguments are meant to be applicable to all package managers, and having arguments that apply to one package manager but not to another is confusing
  • the rush.json file is checked in, and settings that are optimal for one developer may not necessarily apply to another

What is the expected behavior?

These types of settings do not materially impact how the Rush repo may be expected to install, but instead are modifiers to improve developer experience. That's not to say some solution should/shouldn't allow changing things that materially affect install, though this is more of a slippery slope that I'm not trying to address with this issue. I'm personally of the opinion that dangerous settings like that should be tightly controlled by the repo manager (as is currently done with package manager-specific settings in rush.json).

One option would be to use a settings file (or files) in the home directory (under ~/.rush, for example) to store these settings. This file (or files) could be strongly validated against a schema, or compared against a whitelist of known parameters that could be used to warn if a provided value was not known to be supported. The values inside this file would then be passed on to the package manager whenever rush install or rush update is run.

@apostolisms apostolisms added general discussion Not a bug or enhancement, just a discussion needs design The next step is for someone to propose the details of an approach for solving the problem labels Jul 6, 2020
@iclanton iclanton moved this to General Discussions in Bug Triage Aug 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
general discussion Not a bug or enhancement, just a discussion needs design The next step is for someone to propose the details of an approach for solving the problem
Projects
Status: General Discussions
Development

No branches or pull requests

2 participants