Feature request: corepack command to call manager cli (to install project's dependencies using defined package manager)

[olosegres]

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 manager proxy command that would call package manager that is defined in "packageManager" section of project's package.json, so it would be possible to install packages via corepack manager install.

BTW, corepack up does similar, after upgrading package manager it installs project's packages (together with yarn at least), but I think this was not intended by corepack.

[GabenGar]

What about options? Does corepack have to basically support a union of all options and environment variables of install command 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.

[aduh95]

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 up does this

That's a good remark, and certainly a difference with corepack run proposal.

[olosegres]

We can bypass all the nuances for this issue #352 and for #57 if we simply make alias corepack manager to call manager cli and pass all rest arguments as is.

So it would be possible to run corepack manager install or corepack manager run some or corepack 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.

[GabenGar]

npm install options:

[-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 add options:

    -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 information

pnpm install options:

      --[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 packages

Not even touching environment variables, in part because they aren't neatly listed in a particular --help section, 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 potential corepack manager, which at this point is not an abstraction "without thinking".

[olosegres]

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.

[styfle]

If the packageManager field is missing in package.json, what should happen? Throw an error?

[olosegres]

@styfle I'm not sure. Throw an error is ok, but it seems like using npm as a fallback is also a good idea, it may use npm as a fallback and log special message (packageManager is not set, using npm as a fallback)

[aduh95]

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.

[arcanis]

add some sort of global config where the user can specify their favorite package manager

This would lead to people forgetting to set the packageManager field, 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 up command 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 install command, 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.

[olosegres]

@arcanis

I want to improve scenarios that appear when developers working with a lot of projects that uses different package managers.

1. in 99% of cases we call the commands yarn|npm install|add|remove and it would be super convenient not to think about which manager to use and just work by always calling the same command

2. 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 done corepack enable can 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 do corepack enable.

And call it shorter, for example cm (as alias for corepack manager)

And we would work with it through commands
cm install
cm add some
cm remove some

[arcanis]

You already have userland projects that do just that (swpm, yarpm, ...). I don't think it needs to be put inside Corepack, especially since it's not the user experience that package manager authors wish their users to have.

[olosegres]

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 :)

[arcanis]

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.

[olosegres]

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.