Open olosegres opened 7 months ago
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.
This is almost a duplicate of https://github.com/nodejs/corepack/issues/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.
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.
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".
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.
If the packageManager
field is missing in package.json, what should happen? Throw an error?
@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)
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
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.
@arcanis
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|remove
and 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 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
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.
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'spackage.json
, so it would be possible to install packages viacorepack 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.