@patternfly-java/charts 0.0.1 → 0.0.2

package/node/node_modules/npm/man/man1/npm-diff.1

@@ -1,310 +0,0 @@
-.TH "NPM-DIFF" "1" "September 2025" "NPM@11.6.1" ""
-.SH "NAME"
-\fBnpm-diff\fR - The registry diff command
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm diff \[lB]...<paths>\[rB]
-.fi
-.RE
-.SS "Description"
-.P
-Similar to its \fBgit diff\fR counterpart, this command will print diff patches of files for packages published to the npm registry.
-.RS 0
-.IP \(bu 4
-\fBnpm diff --diff=<spec-a> --diff=<spec-b>\fR
-.P
-Compares two package versions using their registry specifiers, e.g: \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0\fR. It's also possible to compare across forks of any package, e.g: \fBnpm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0\fR.
-.P
-Any valid spec can be used, so that it's also possible to compare directories or git repositories, e.g: \fBnpm diff --diff=pkg@latest --diff=./packages/pkg\fR
-.P
-Here's an example comparing two different versions of a package named \fBabbrev\fR from the registry:
-.P
-.RS 2
-.nf
-npm diff --diff=abbrev@1.1.0 --diff=abbrev@1.1.1
-.fi
-.RE
-.P
-On success, output looks like:
-.P
-.RS 2
-.nf
-diff --git a/package.json b/package.json
-index v1.1.0..v1.1.1 100644
---- a/package.json
-+++ b/package.json
-@@ -1,6 +1,6 @@
- {
-   "name": "abbrev",
--  "version": "1.1.0",
-+  "version": "1.1.1",
-   "description": "Like ruby's abbrev module, but in js",
-   "author": "Isaac Z. Schlueter <i@izs.me>",
-   "main": "abbrev.js",
-.fi
-.RE
-.P
-Given the flexible nature of npm specs, you can also target local directories or git repos just like when using \fBnpm install\fR:
-.P
-.RS 2
-.nf
-npm diff --diff=https://github.com/npm/libnpmdiff --diff=./local-path
-.fi
-.RE
-.P
-In the example above we can compare the contents from the package installed from the git repo at \fBgithub.com/npm/libnpmdiff\fR with the contents of the \fB./local-path\fR that contains a valid package, such as a modified copy of the original.
-.IP \(bu 4
-\fBnpm diff\fR (in a package directory, no arguments):
-.P
-If the package is published to the registry, \fBnpm diff\fR will fetch the tarball version tagged as \fBlatest\fR (this value can be configured using the \fBtag\fR option) and proceed to compare the contents of files present in that tarball, with the current files in your local file system.
-.P
-This workflow provides a handy way for package authors to see what package-tracked files have been changed in comparison with the latest published version of that package.
-.IP \(bu 4
-\fBnpm diff --diff=<pkg-name>\fR (in a package directory):
-.P
-When using a single package name (with no version or tag specifier) as an argument, \fBnpm diff\fR will work in a similar way to \fB\[rs]fBnpm-outdated\[rs]fR\fR \fI\(lanpm-outdated\(ra\fR and reach for the registry to figure out what current published version of the package named \fB<pkg-name>\fR will satisfy its dependent declared semver-range. Once that specific version is known \fBnpm diff\fR will print diff patches comparing the current version of \fB<pkg-name>\fR found in the local file system with that specific version returned by the registry.
-.P
-Given a package named \fBabbrev\fR that is currently installed:
-.P
-.RS 2
-.nf
-npm diff --diff=abbrev
-.fi
-.RE
-.P
-That will request from the registry its most up to date version and will print a diff output comparing the currently installed version to this newer one if the version numbers are not the same.
-.IP \(bu 4
-\fBnpm diff --diff=<spec-a>\fR (in a package directory):
-.P
-Similar to using only a single package name, it's also possible to declare a full registry specifier version if you wish to compare the local version of an installed package with the specific version/tag/semver-range provided in \fB<spec-a>\fR.
-.P
-An example: assuming \fBpkg@1.0.0\fR is installed in the current \fBnode_modules\fR folder, running:
-.P
-.RS 2
-.nf
-npm diff --diff=pkg@2.0.0
-.fi
-.RE
-.P
-It will effectively be an alias to \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@2.0.0\fR.
-.IP \(bu 4
-\fBnpm diff --diff=<semver-a> \[lB]--diff=<semver-b>\[rB]\fR (in a package directory):
-.P
-Using \fBnpm diff\fR along with semver-valid version numbers is a shorthand to compare different versions of the current package.
-.P
-It needs to be run from a package directory, such that for a package named \fBpkg\fR running \fBnpm diff --diff=1.0.0 --diff=1.0.1\fR is the same as running \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1\fR.
-.P
-If only a single argument \fB<version-a>\fR is provided, then the current local file system is going to be compared against that version.
-.P
-Here's an example comparing two specific versions (published to the configured registry) of the current project directory:
-.P
-.RS 2
-.nf
-npm diff --diff=1.0.0 --diff=1.1.0
-.fi
-.RE
-.RE 0
-
-.P
-Note that tag names are not valid \fB--diff\fR argument values, if you wish to compare to a published tag, you must use the \fBpkg@tagname\fR syntax.
-.SS "Filtering files"
-.P
-It's possible to also specify positional arguments using file names or globs pattern matching in order to limit the result of diff patches to only a subset of files for a given package, e.g:
-.P
-.RS 2
-.nf
-npm diff --diff=pkg@2 ./lib/ CHANGELOG.md
-.fi
-.RE
-.P
-In the example above the diff output is only going to print contents of files located within the folder \fB./lib/\fR and changed lines of code within the \fBCHANGELOG.md\fR file.
-.SS "Configuration"
-.SS "\fBdiff\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-Define arguments to compare in \fBnpm diff\fR.
-.SS "\fBdiff-name-only\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Prints only filenames when using \fBnpm diff\fR.
-.SS "\fBdiff-unified\fR"
-.RS 0
-.IP \(bu 4
-Default: 3
-.IP \(bu 4
-Type: Number
-.RE 0
-
-.P
-The number of lines of context to print in \fBnpm diff\fR.
-.SS "\fBdiff-ignore-all-space\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Ignore whitespace when comparing lines in \fBnpm diff\fR.
-.SS "\fBdiff-no-prefix\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Do not show any source or destination prefix in \fBnpm diff\fR output.
-.P
-Note: this causes \fBnpm diff\fR to ignore the \fB--diff-src-prefix\fR and \fB--diff-dst-prefix\fR configs.
-.SS "\fBdiff-src-prefix\fR"
-.RS 0
-.IP \(bu 4
-Default: "a/"
-.IP \(bu 4
-Type: String
-.RE 0
-
-.P
-Source prefix to be used in \fBnpm diff\fR output.
-.SS "\fBdiff-dst-prefix\fR"
-.RS 0
-.IP \(bu 4
-Default: "b/"
-.IP \(bu 4
-Type: String
-.RE 0
-
-.P
-Destination prefix to be used in \fBnpm diff\fR output.
-.SS "\fBdiff-text\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Treat all files as text in \fBnpm diff\fR.
-.SS "\fBglobal\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
-.RS 0
-.IP \(bu 4
-packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
-.IP \(bu 4
-bin files are linked to \fB{prefix}/bin\fR
-.IP \(bu 4
-man pages are linked to \fB{prefix}/share/man\fR
-.RE 0
-
-.SS "\fBtag\fR"
-.RS 0
-.IP \(bu 4
-Default: "latest"
-.IP \(bu 4
-Type: String
-.RE 0
-
-.P
-If you ask npm to install a package and don't tell it a specific version, then it will install the specified tag.
-.P
-It is the tag added to the package@version specified in the \fBnpm dist-tag
-add\fR command, if no explicit tag is given.
-.P
-When used by the \fBnpm diff\fR command, this is the tag used to fetch the tarball that will be compared with the local files by default.
-.P
-If used in the \fBnpm publish\fR command, this is the tag that will be added to the package submitted to the registry.
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SH "SEE ALSO"
-.RS 0
-.IP \(bu 4
-npm help outdated
-.IP \(bu 4
-npm help install
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help registry
-.RE 0

package/node/node_modules/npm/man/man1/npm-dist-tag.1

@@ -1,144 +0,0 @@
-.TH "NPM-DIST-TAG" "1" "September 2025" "NPM@11.6.1" ""
-.SH "NAME"
-\fBnpm-dist-tag\fR - Modify package distribution tags
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm dist-tag add <package-spec (with version)> \[lB]<tag>\[rB]
-npm dist-tag rm <package-spec> <tag>
-npm dist-tag ls \[lB]<package-spec>\[rB]
-
-alias: dist-tags
-.fi
-.RE
-.SS "Description"
-.P
-Add, remove, and enumerate distribution tags on a package:
-.RS 0
-.IP \(bu 4
-add: Tags the specified version of the package with the specified tag, or the \fB\[rs]fB--tag\[rs]fR config\fR \fI\(la/using-npm/config#tag\(ra\fR if not specified. If you have two-factor authentication on auth-and-writes then you\[cq]ll need to include a one-time password on the command line with \fB--otp <one-time password>\fR, or go through a second factor flow based on your \fBauthtype\fR.
-.IP \(bu 4
-rm: Clear a tag that is no longer in use from the package. If you have two-factor authentication on auth-and-writes then you\[cq]ll need to include a one-time password on the command line with \fB--otp <one-time password>\fR, or go through a second factor flow based on your \fBauthtype\fR
-.IP \(bu 4
-ls: Show all of the dist-tags for a package, defaulting to the package in the current prefix. This is the default action if none is specified.
-.RE 0
-
-.P
-A tag can be used when installing packages as a reference to a version instead of using a specific version number:
-.P
-.RS 2
-.nf
-npm install <name>@<tag>
-.fi
-.RE
-.P
-When installing dependencies, a preferred tagged version may be specified:
-.P
-.RS 2
-.nf
-npm install --tag <tag>
-.fi
-.RE
-.P
-(This also applies to any other commands that resolve and install dependencies, such as \fBnpm dedupe\fR, \fBnpm update\fR, and \fBnpm audit fix\fR.)
-.P
-Publishing a package sets the \fBlatest\fR tag to the published version unless the \fB--tag\fR option is used. For example, \fBnpm publish --tag=beta\fR.
-.P
-By default, \fBnpm install <pkg>\fR (without any \fB@<version>\fR or \fB@<tag>\fR specifier) installs the \fBlatest\fR tag.
-.SS "Purpose"
-.P
-Tags can be used to provide an alias instead of version numbers.
-.P
-For example, a project might choose to have multiple streams of development and use a different tag for each stream, e.g., \fBstable\fR, \fBbeta\fR, \fBdev\fR, \fBcanary\fR.
-.P
-By default, the \fBlatest\fR tag is used by npm to identify the current version of a package, and \fBnpm install <pkg>\fR (without any \fB@<version>\fR or \fB@<tag>\fR specifier) installs the \fBlatest\fR tag. Typically, projects only use the \fBlatest\fR tag for stable release versions, and use other tags for unstable versions such as prereleases.
-.P
-The \fBnext\fR tag is used by some projects to identify the upcoming version.
-.P
-Other than \fBlatest\fR, no tag has any special significance to npm itself.
-.SS "Caveats"
-.P
-This command used to be known as \fBnpm tag\fR, which only created new tags, and so had a different syntax.
-.P
-Tags must share a namespace with version numbers, because they are specified in the same slot: \fBnpm install <pkg>@<version>\fR vs \fBnpm install <pkg>@<tag>\fR.
-.P
-Tags that can be interpreted as valid semver ranges will be rejected. For example, \fBv1.4\fR cannot be used as a tag, because it is interpreted by semver as \fB>=1.4.0 <1.5.0\fR. See \fI\(lahttps://github.com/npm/npm/issues/6082\(ra\fR.
-.P
-The simplest way to avoid semver problems with tags is to use tags that do not begin with a number or the letter \fBv\fR.
-.SS "Configuration"
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help "package spec"
-.IP \(bu 4
-npm help publish
-.IP \(bu 4
-npm help install
-.IP \(bu 4
-npm help dedupe
-.IP \(bu 4
-npm help registry
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help npmrc
-.RE 0

package/node/node_modules/npm/man/man1/npm-docs.1

@@ -1,113 +0,0 @@
-.TH "NPM-DOCS" "1" "September 2025" "NPM@11.6.1" ""
-.SH "NAME"
-\fBnpm-docs\fR - Open documentation for a package in a web browser
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm docs \[lB]<pkgname> \[lB]<pkgname> ...\[rB]\[rB]
-
-alias: home
-.fi
-.RE
-.SS "Description"
-.P
-This command tries to guess at the likely location of a package's documentation URL, and then tries to open it using the \fB\[rs]fB--browser\[rs]fR config\fR \fI\(la/using-npm/config#browser\(ra\fR param. You can pass multiple package names at once. If no package name is provided, it will search for a \fBpackage.json\fR in the current folder and use the \fBname\fR property.
-.SS "Configuration"
-.SS "\fBbrowser\fR"
-.RS 0
-.IP \(bu 4
-Default: macOS: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg-open"\fR
-.IP \(bu 4
-Type: null, Boolean, or String
-.RE 0
-
-.P
-The browser that is called by npm commands to open websites.
-.P
-Set to \fBfalse\fR to suppress browser behavior and instead print urls to terminal.
-.P
-Set to \fBtrue\fR to use default system URL opener.
-.SS "\fBregistry\fR"
-.RS 0
-.IP \(bu 4
-Default: "https://registry.npmjs.org/"
-.IP \(bu 4
-Type: URL
-.RE 0
-
-.P
-The base URL of the npm registry.
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help view
-.IP \(bu 4
-npm help publish
-.IP \(bu 4
-npm help registry
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help npmrc
-.IP \(bu 4
-\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
-.RE 0

package/node/node_modules/npm/man/man1/npm-doctor.1

@@ -1,82 +0,0 @@
-.TH "NPM-DOCTOR" "1" "September 2025" "NPM@11.6.1" ""
-.SH "NAME"
-\fBnpm-doctor\fR - Check the health of your npm environment
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm doctor \[lB]connection\[rB] \[lB]registry\[rB] \[lB]versions\[rB] \[lB]environment\[rB] \[lB]permissions\[rB] \[lB]cache\[rB]
-.fi
-.RE
-.P
-Note: This command is unaware of workspaces.
-.SS "Description"
-.P
-\fBnpm doctor\fR runs a set of checks to ensure that your npm installation has what it needs to manage your JavaScript packages. npm is mostly a standalone tool, but it does have some basic requirements that must be met:
-.RS 0
-.IP \(bu 4
-Node.js and git must be executable by npm.
-.IP \(bu 4
-The primary npm registry, \fBregistry.npmjs.com\fR, or another service that uses the registry API, is available.
-.IP \(bu 4
-The directories that npm uses, \fBnode_modules\fR (both locally and globally), exist and can be written by the current user.
-.IP \(bu 4
-The npm cache exists, and the package tarballs within it aren't corrupt.
-.RE 0
-
-.P
-Without all of these working properly, npm may not work properly. Many issues are often attributable to things that are outside npm's code base, so \fBnpm doctor\fR confirms that the npm installation is in a good state.
-.P
-Also, in addition to this, there are also very many issue reports due to using old versions of npm. Since npm is constantly improving, running \fBnpm@latest\fR is better than an old version.
-.P
-\fBnpm doctor\fR verifies the following items in your environment, and if there are any recommended changes, it will display them. By default npm runs all of these checks. You can limit what checks are ran by specifying them as extra arguments.
-.SS "\fBConnecting to the registry\fR"
-.P
-By default, npm installs from the primary npm registry, \fBregistry.npmjs.org\fR. \fBnpm doctor\fR hits a special connection testing endpoint within the registry. This can also be checked with \fBnpm ping\fR. If this check fails, you may be using a proxy that needs to be configured, or may need to talk to your IT staff to get access over HTTPS to \fBregistry.npmjs.org\fR.
-.P
-This check is done against whichever registry you've configured (you can see what that is by running \fBnpm config get registry\fR), and if you're using a private registry that doesn't support the \fB/whoami\fR endpoint supported by the primary registry, this check may fail.
-.SS "\fBChecking npm version\fR"
-.P
-While Node.js may come bundled with a particular version of npm, it's the policy of the CLI team that we recommend all users run \fBnpm@latest\fR if they can. As the CLI is maintained by a small team of contributors, there are only resources for a single line of development, so npm's own long-term support releases typically only receive critical security and regression fixes. The team believes that the latest tested version of npm is almost always likely to be the most functional and defect-free version of npm.
-.SS "\fBChecking node version\fR"
-.P
-For most users, in most circumstances, the best version of Node will be the latest long-term support (LTS) release. Those of you who want access to new ECMAscript features or bleeding-edge changes to Node's standard library may be running a newer version, and some may be required to run an older version of Node because of enterprise change control policies. That's OK! But in general, the npm team recommends that most users run Node.js LTS.
-.SS "\fBChecking configured npm registry\fR"
-.P
-You may be installing from private package registries for your project or company. That's great! Others may be following tutorials or StackOverflow questions in an effort to troubleshoot problems you may be having. Sometimes, this may entail changing the registry you're pointing at. This part of \fBnpm doctor\fR just lets you, and maybe whoever's helping you with support, know that you're not using the default registry.
-.SS "\fBChecking for git executable in PATH\fR"
-.P
-While it's documented in the README, it may not be obvious that npm needs Git installed to do many of the things that it does. Also, in some cases \[en] especially on Windows \[en] you may have Git set up in such a way that it's not accessible via your \fBPATH\fR so that npm can find it. This check ensures that Git is available.
-.SS "Permissions checks"
-.RS 0
-.IP \(bu 4
-Your cache must be readable and writable by the user running npm.
-.IP \(bu 4
-Global package binaries must be writable by the user running npm.
-.IP \(bu 4
-Your local \fBnode_modules\fR path, if you're running \fBnpm doctor\fR with a project directory, must be readable and writable by the user running npm.
-.RE 0
-
-.SS "Validate the checksums of cached packages"
-.P
-When an npm package is published, the publishing process generates a checksum that npm uses at install time to verify that the package didn't get corrupted in transit. \fBnpm doctor\fR uses these checksums to validate the package tarballs in your local cache (you can see where that cache is located with \fBnpm config get cache\fR). In the event that there are corrupt packages in your cache, you should probably run \fBnpm cache clean -f\fR and reset the cache.
-.SS "Configuration"
-.SS "\fBregistry\fR"
-.RS 0
-.IP \(bu 4
-Default: "https://registry.npmjs.org/"
-.IP \(bu 4
-Type: URL
-.RE 0
-
-.P
-The base URL of the npm registry.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help bugs
-.IP \(bu 4
-npm help help
-.IP \(bu 4
-npm help ping
-.RE 0

package/node/node_modules/npm/man/man1/npm-edit.1

@@ -1,43 +0,0 @@
-.TH "NPM-EDIT" "1" "September 2025" "NPM@11.6.1" ""
-.SH "NAME"
-\fBnpm-edit\fR - Edit an installed package
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm edit <pkg>\[lB]/<subpkg>...\[rB]
-.fi
-.RE
-.P
-Note: This command is unaware of workspaces.
-.SS "Description"
-.P
-Selects a dependency in the current project and opens the package folder in the default editor (or whatever you've configured as the npm \fBeditor\fR config -- see \fB\[rs]fBnpm-config\[rs]fR\fR \fI\(lanpm-config\(ra\fR.)
-.P
-After it has been edited, the package is rebuilt so as to pick up any changes in compiled packages.
-.P
-For instance, you can do \fBnpm install connect\fR to install connect into your package, and then \fBnpm edit connect\fR to make a few changes to your locally installed copy.
-.SS "Configuration"
-.SS "\fBeditor\fR"
-.RS 0
-.IP \(bu 4
-Default: The EDITOR or VISUAL environment variables, or '%SYSTEMROOT%\[rs]notepad.exe' on Windows, or 'vi' on Unix systems
-.IP \(bu 4
-Type: String
-.RE 0
-
-.P
-The command to run for \fBnpm edit\fR and \fBnpm config edit\fR.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help folders
-.IP \(bu 4
-npm help explore
-.IP \(bu 4
-npm help install
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help npmrc
-.RE 0