Repository navigation
Feature request: corepack command to call manager cli (to install project's dependencies using defined package manager) #352
Description
Activity
- changed the title
[-]Feature request: Corepack command to install packages using defined package manager[/-][+]Feature request: Corepack command to install project's packages using defined package manager[/+]on Jan 12, 2024 - changed the title
[-]Feature request: Corepack command to install project's packages using defined package manager[/-][+]Feature request: manager-agnostic corepack command to install project's packages using defined package manager[/+]on Jan 12, 2024 - changed the title
[-]Feature request: manager-agnostic corepack command to install project's packages using defined package manager[/-][+]Feature request: manager-agnostic corepack command to install project's dependencies using defined package manager[/+]on Jan 12, 2024 What about options? Does corepack have to basically support a union of all options and environment variables of
installcommand of all package managers (and all their versions) it can support? Do note if a particular repo depends on the arguments of a package manager and corepack doesn't support them, the whole "without thinking" abstraction crumbles.This is almost a duplicate of #57, the same arguments for and against apply here as well for the most part, so you might find the read interesting.
BTW,
corepack updoes thisThat's a good remark, and certainly a difference with
corepack runproposal.Reacted by StevenWe can bypass all the nuances for this issue #352 and for #57 if we simply make alias
corepack managerto call manager cli and pass all rest arguments as is.So it would be possible to run
corepack manager installorcorepack manager run someorcorepack manager add somepackage.If some manager does not support passed command, corepack won't care, user will see error from the manager and this behavior will be expected.
Probably described solution is also covers needs that this draft is trying to solve.
Reacted by Steven- changed the title
[-]Feature request: manager-agnostic corepack command to install project's dependencies using defined package manager[/-][+]Feature request: corepack command to call manager cli (to install project's dependencies using defined package manager)[/+]on Jan 12, 2024 npm installoptions:[-S|--save|--no-save|--save-prod|--save-dev|--save-optional|--save-peer|--save-bundle] [-E|--save-exact] [-g|--global] [--global-style] [--legacy-bundling] [--omit <dev|optional|peer> [--omit <dev|optional|peer> ...]] [--strict-peer-deps] [--no-package-lock] [--foreground-scripts] [--ignore-scripts] [--no-audit] [--no-bin-links] [--no-fund] [--dry-run] [-w|--workspace <workspace-name> [-w|--workspace <workspace-name> ...]] [-ws|--workspaces] [--include-workspace-root]yarn addoptions:-v, --version output the version number --no-default-rc prevent Yarn from automatically detecting yarnrc and npmrc files --use-yarnrc <path> specifies a yarnrc file that Yarn should use (.yarnrc only, not .npmrc) (default: ) --verbose output verbose messages on internal operations --offline trigger an error if any required dependencies are not available in local cache --prefer-offline use network only if dependencies are not available in local cache --enable-pnp, --pnp enable the Plug'n'Play installation --disable-pnp disable the Plug'n'Play installation --strict-semver --json format Yarn log messages as lines of JSON (see jsonlines.org) --ignore-scripts don't run lifecycle scripts --har save HAR output of network traffic --ignore-platform ignore platform checks --ignore-engines ignore engines check --ignore-optional ignore optional dependencies --force install and build packages even if they were built before, overwrite lockfile --skip-integrity-check run install without checking if node_modules is installed --check-files install will verify file tree of packages for consistency --no-bin-links don't generate bin links when setting up packages --flat only allow one version of a package --prod, --production [prod] --no-lockfile don't read or generate a lockfile --pure-lockfile don't generate a lockfile --frozen-lockfile don't generate a lockfile and fail if an update is needed --update-checksums update package checksums from current repository --link-duplicates create hardlinks to the repeated modules in node_modules --link-folder <path> specify a custom folder to store global links --global-folder <path> specify a custom folder to store global packages --modules-folder <path> rather than installing modules into the node_modules folder relative to the cwd, output them here --preferred-cache-folder <path> specify a custom folder to store the yarn cache if possible --cache-folder <path> specify a custom folder that must be used to store the yarn cache --mutex <type>[:specifier] use a mutex to ensure only one yarn instance is executing --emoji [bool] enable emoji in output (default: false) -s, --silent skip Yarn console logs, other types of logs (script output) will be printed --cwd <cwd> working directory to use (default: C:\Users\andrei\projects\json-schema-to-typescript) --proxy <host> --https-proxy <host> --registry <url> override configuration registry --no-progress disable progress bar --network-concurrency <number> maximum number of concurrent network requests --network-timeout <milliseconds> TCP timeout for network requests --non-interactive do not show interactive prompts --scripts-prepend-node-path [bool] prepend the node executable dir to the PATH in scripts --no-node-version-check do not warn when using a potentially unsupported Node version --focus Focus on a single workspace by installing remote copies of its sibling workspaces. --otp <otpcode> one-time password for two factor authentication -W, --ignore-workspace-root-check required to run yarn add inside a workspace root -D, --dev save package to your `devDependencies` -P, --peer save package to your `peerDependencies` -O, --optional save package to your `optionalDependencies` -E, --exact install exact version -T, --tilde install most recent release with the same minor version -A, --audit Run vulnerability audit on installed packages -h, --help output usage informationpnpm installoptions:--[no-]color Controls colors in the output. By default, output is always colored when it goes directly to a terminal --[no-]verify-store-integrity If false, doesn't check whether packages in the store were mutated --child-concurrency <number> Controls the number of child processes run parallelly to build node modules -D, --dev Only `devDependencies` are installed regardless of the `NODE_ENV` -C, --dir <dir> Change to directory <dir> (default: C:\Users\andrei\projects\json-schema-to- typescript) --frozen-lockfile Don't generate a lockfile and fail if an update is needed --global-dir Specify a custom directory to store global packages -h, --help Output usage information --hoist-pattern <pattern> Hoist all dependencies matching the pattern to `node_modules/.pnpm/node_modules`. The default pattern is * and matches everything. Hoisted packages can be required by any dependencies, so it is an emulation of a flat node_modules --ignore-pnpmfile Disable pnpm hooks defined in .pnpmfile.cjs --ignore-scripts Don't run lifecycle scripts --lockfile-dir <dir> The directory in which the pnpm-lock.yaml of the package will be created. Several projects may share a single lockfile. --lockfile-only Dependencies are not downloaded. Only `pnpm-lock.yaml` is updated --loglevel <level> What level of logs to report. Any logs at or higher than the given level will be shown. Levels (lowest to highest): debug, info, warn, error. Or use "--silent" to turn off all logging. --modules-dir <dir> The directory in which dependencies will be installed (instead of node_modules) --network-concurrency <number> Maximum number of concurrent network requests --no-hoist Dependencies inside the modules directory will have access only to their listed dependencies --no-lockfile Don't read or generate a `pnpm-lock.yaml` file --no-optional `optionalDependencies` are not installed --offline Trigger an error if any required dependencies are not available in local store --package-import-method auto Clones/hardlinks or copies packages. The selected method depends from the file system --package-import-method clone Clone (aka copy-on-write) packages from the store --package-import-method copy Copy packages from the store --package-import-method hardlink Hardlink packages from the store --prefer-frozen-lockfile If the available `pnpm-lock.yaml` satisfies the `package.json` then perform a headless installation --prefer-offline Skip staleness checks for cached data, but request missing data from the server -P, --prod Packages in `devDependencies` won't be installed --public-hoist-pattern <pattern> Hoist all dependencies matching the pattern to the root of the modules directory -r, --recursive Run installation recursively in every package found in subdirectories. For options that may be used with `-r`, see "pnpm help recursive" --shamefully-hoist All the subdeps will be hoisted into the root node_modules. Your code will have access to them --store-dir <dir> The directory in which all the packages are saved on the disk --stream Stream output from child processes immediately, prefixed with the originating package directory. This allows output from different packages to be interleaved. --strict-peer-dependencies Fail on missing or invalid peer dependencies --use-running-store-server Only allows installation with a store server. If no store server is running, installation will fail --use-stderr Divert all output to stderr --use-store-server Starts a store server in the background. The store server will keep running after installation is done. To stop the store server, run `pnpm server stop` --virtual-store-dir <dir> The directory with links to the store (default is node_modules/.pnpm). All direct and indirect dependencies of the project are linked into this directory -w, --workspace-root Run the command on the root workspace project Output: --reporter append-only The output is always appended to the end. No cursor manipulations are performed --reporter default The default reporter when the stdout is TTY --reporter ndjson The most verbose reporter. Prints all logs in ndjson format -s, --silent, --reporter silent No output is logged to the console, except fatal errors Filtering options (run the command only on packages that satisfy at least one of the selectors): --filter !<selector> If a selector starts with ! (or \! in zsh), it means the packages matching the selector must be excluded. E.g., "pnpm --filter !foo" selects all packages except "foo" --filter . Includes all packages that are under the current working directory --filter ...^<pattern> Includes only the direct and indirect dependents of the matched packages without including the matched packages themselves. ^ must be doubled at the Windows Command Prompt. E.g.: ...^foo (...^^foo in Command Prompt) --filter ...<pattern> Includes all direct and indirect dependents of the matched packages. E.g.: ...foo, "...@bar/*" --filter ./<dir> Includes all packages that are inside a given subdirectory. E.g.: ./components --filter "[<since>]" Includes all packages changed since the specified commit/branch. E.g.: "[master]", "[HEAD~2]". It may be used together with "...". So, for instance, "...[HEAD~1]" selects all packages changed in the last commit and their dependents --filter {<dir>} Includes all projects that are under the specified directory. It may be used with "..." to select dependents/dependencies as well. It also may be combined with "[<since>]". For instance, all changed projects inside a directory: "{packages}[origin/master]" --filter <pattern> Restricts the scope to package names matching the given pattern. E.g.: foo, "@bar/*" --filter <pattern>... Includes all direct and indirect dependencies of the matched packages. E.g.: foo... --filter <pattern>^... Includes only the direct and indirect dependencies of the matched packages without including the matched packages themselves. ^ must be doubled at the Windows Command Prompt. E.g.: foo^... (foo^^... in Command Prompt) --filter-prod <pattern> Restricts the scope to package names matching the given pattern similar to --filter, but it ignores devDependencies when searching for dependencies and dependents. --test-pattern <pattern> Defines files related to tests. Useful with the changed since filter. When selecting only changed packages and their dependent packages, the dependent packages will be ignored in case a package has changes only in tests. Usage example: pnpm --filter="...[origin/master]" --test-pattern="test/*" test Experimental options: --side-effects-cache Use or cache the results of (pre/post)install hooks --side-effects-cache-readonly Only use the side effects cache if present, do not create it for new packagesNot even touching environment variables, in part because they aren't neatly listed in a particular
--helpsection, so their situation is even worse.
As you can see they have wildly different APIs, so you have to be keenly aware of what manager-specific options you pass to a potentialcorepack manager, which at this point is not an abstraction "without thinking".As I wrote, corepack should not care, user will see error from the manager and this behavior will be expected.
Apart from the logged error, it would be nice if corepack log the name of the manager that is called at the beginning.
Reacted by StevenIf the
packageManagerfield is missing in package.json, what should happen? Throw an error?IMO it would be a mistake to set npm as the default (Corepack goal is to provide a level playing field). A more fair behavior would be:
- add some sort of global config where the user can specify their favorite package manager.
- If no global package manager has been set, it makes sense to throw.
Reacted by Stevenadd some sort of global config where the user can specify their favorite package manager
This would lead to people forgetting to set the
packageManagerfield, then once in someone else's machine it would break.I'd like to better understand the workflow you'd like to improve here. In the case of
up, the install automatically runs because:-
It's a command the user would have had to run anyway after the upgrade, so why not run it for them.
-
It's a command that requires some knowledge of the project infrastructure, so the package manager isn't hidden away.
-
The
corepack upcommand also does something unique to Corepack (updating the field), so it's not a raw mirror of a package manager command.
If we provided a
corepack installcommand, I wouldn't want it to become the entry point into a project - I'd want my users to know what's the tool they use all along the way.If some commands should be run through Corepack and some others should be run through individual package managers, I strongly suspect things will get more confusing overall, not less, with some tutorials using one version or the other, and newcomers not understanding the nuances.
Corepack already does a lot, I don't see providing a unified user experience as part of its goals.
-
I want to improve scenarios that appear when developers working with a lot of projects that uses different package managers.
-
in 99% of cases we call the commands
yarn|npm install|add|removeand it would be super convenient not to think about which manager to use and just work by always calling the same command -
Now I also understand that sometimes we update nodejs (for example via nvm) and forget to do
corepack enable, and also new people who have not donecorepack enablecan start working with the code.
In this case, shim will not work.
It would be also convenient not to think about enabling corepack.
I got the idea that it would be even better to make a separate cli that would call the actual
packageManager, without having to docorepack enable.And call it shorter, for example
cm(as alias forcorepack manager)And we would work with it through commands
cm install
cm add some
cm remove someReacted by Steven-
This is not the same at least because it requires manual install of it.
It is desirable to make some kind of standard entry point.
Manual install of userland lib is also an unpleasant moment for CI.In general, before starting the creation of corepack, it was possible to invite everyone to use yarpm :)
It doesn't make it impossible, and it doesn't even make it harder.
I understand it would be more convenient for you if it was a core behavior of Corepack simply because it's shipped with Node by default, but the same could be said of pretty much every CLI tool.
We shouldn't expand the scope of Corepack in a way that would change how packages managers are used. Its only purpose is to change how they are installed.
I'm not suggesting giving corepack the knowledge of how to use package managers.
I just want a command that would call the cli of package manager.Reacted by Steven, Aleksandr Gorlov, Augusto Moura and Moisés Santos
I would like to install packages in a project without thinking about which package manager should be used in this project.
This can be solved with the
corepack managerproxy command that would call package manager that is defined in"packageManager"section of project'spackage.json, so it would be possible to install packages viacorepack manager install.BTW,
corepack updoes similar, after upgrading package manager it installs project's packages (together with yarn at least), but I think this was not intended by corepack.