NPM already provides the hook scripts feature, which allows executable scipts to be placed in node_modules/.hooks/ and have them run for npm lifecycle events. But as far as I'm aware, there's currently no easy way for a package to link their hook scripts in this way, except by manually doing the work or writing a custom script to do it.

It would be extremely useful if npm provided a "hooks" field in package.json, similar to the existing "bin" field, which provides a way to specify paths to scripts that should be linked from the .hooks directory.

I will contribute a PR shortly to implement this.

What / Why

The v1's README.md has a link to Contributor Guide, but this link is broken.

I found this commit and there is my question: **why were CODE_OF_CONDUCT.md, CONTRIBUTING.md, ISSUE_TEMPLATE and PULL_REQUEST_TEMPLATE deleted?

Who

• @isaacs

What / Why

Firstly please forgive any assertions I make that are completely wrong - I'm doing my best to understand something that is completely alien to me.

https://docs.npmjs.com/cli/v7/configuring-npm/package-json states 3 ways to add a man page in a package.json:

• directories.man: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#directoriesman
• man String: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#man
• man Array: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#man

I do not know whether the intention is for directories.man to be supported by bin-links or as a process managed by npm or Arborist that would interrogate the directory and convert its contents into a man Array property before sending it to bin-links.

Giving the benefit of the doubt that it is the latter - I would expect per the documentation for bin-links to support either a String or an Array for a man property, however it currently only supports an Array:

I do not know the progeny of this toolset and what begat what so as to know if this is a feature request for string support, or a bug request that expected string support is missing - but it seems to be missing either way.

References

• Related to npm/cli#2914
• Related to https://github.com/npm/arborist/issues/312

Re npm/cli#1103

Refs: nodejs/node#32321

Summary: process.umask() (no args) will be deprecated and removed.

I couldn't quite divine what lib/config/defaults.js uses process.umask() for but in most cases you don't need to deal with the umask directly - the operating system will apply it automatically.

Example:

const mode = 0o777 & ~process.umask();
fs.mkdirSync(dir, mode);

Computing the file mode that way is superfluous, it can be replaced with just this:

fs.mkdirSync(dir, 0o777);

Currently we use the process.umask() value to determine the appropriate mode for executable files on the system.

const fixBin = file => chmod(file, execMode)
  .then(() => isWindowsHashbangFile(file))
  .then(isWHB => isWHB ? dos2Unix(file) : null)

Since this is only done after the file is created (and it is created without the knowledge that it will eventually need to be an executable script), we can't just rely on default file creation masking, since chmod isn't limited by that.

If we don't read process.umask, we risk making all executable files world-writable (or even just group-writable) which is a security risk.

As I can see it, the only way to avoid this would be to have pacote take note of executable file targets at unpack time, and create them with a 0o777 mode, regardless of what the archive entry says, and then also tell tar not to chmod them to 0o777 after creation.

Probably this will require a way to provide chmod:false to tar.Unpack anyway, so that pacote can just set the creation modes to 0o666/0o777 and ignore the specific mode found in the archive.

cc: @bnoordhuis

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When using linkbins/linkbin where the same file is linked to multiple times the code ends up conceivably modifying the same file on multiple thread in an unsafe manner. I believe this is the root cause of a large number of reported problems with npm install (e.g. https://duckduckgo.com/?q=npm+install+ENOENT+chmod&ia=web)

The complete possible effect of linkbin is to link to a target file, chmod and then fix the target to insure it does not use CR-LF line endings. These steps are performed using asynchronous processing for each link request. This means that if the same target file is being linked to multiple times that these steps would occur in parallel.

There are various exit/escape conditions for the steps that make race condition smaller but do not eliminate it. Specifically the triggering condition require that the link target is a script (starts with #!), that the target have CR/LF in the first line and that it is being linked to multiple times (meaning multiple linkbin/linkbins with the same target file). An example of this trying to use the requirejs package on Windows where line endings were changed to CR/LF in the NPM repo when the package was acquired (e.g. from Github).

Given that these steps could interfere which each other (e.g. on Windows) there needs to be some means to insure that with respect to a single target file they are not performed in parallel. One easy way to accomplish this would be to perform each linkbin on completion of the prior one. Another way would be to setup an internal target file exclusion mechanism that is checked before proceeding with linkbin.

I am using older version of NPM and nodeJS but I've reviewed the code in the develop branch and do not see code that avoids this race condition.

Expected Behavior

linkbins with the same target file should work without issue.

Steps To Reproduce

No response

Environment

• npm: 5.6.0
• Node: 6.11.1
• OS: centos 7.2.1511
• platform: Docker 4.16.3 on Windows 11 using Hyper-V

Expected: 100% coverage
Actual: not even close

What / Why

Creating an unscoped alias of scoped package does not place bin files, the parent directory calculation incorrectly points to project directory.

  var parent = pkg.name && pkg.name[0] === '@' ? path.dirname(path.dirname(folder)) : path.dirname(folder)

Tried to print parameters passed in, seems that _requested.name contains the alias name I requested:

pkg: {
  name: '@jixun/tape',
  version: '4.13.1-patch3',
  // -- snip --
  _requested: Result {
    type: 'alias',          // install as alias
    name: 'my-tape',        // the name I want to use
    escapedName: 'my-tape',
    raw: 'my-tape@npm:@jixun/[email protected]',
    // -- snip --
  },
  // -- snip --
}

My quick patch for v1.1.7:

$ git diff
diff --git a/index.js b/index.js
index 79c2cb5..a06720a 100644
--- a/index.js
+++ b/index.js
@@ -23,7 +23,8 @@ function binLinks (pkg, folder, global, opts, cb) {
   // if it's global, and folder is in {prefix}/node_modules,
   // then bins are in {prefix}/bin
   // otherwise, then bins are in folder/../.bin
-  var parent = pkg.name && pkg.name[0] === '@' ? path.dirname(path.dirname(folder)) : path.dirname(folder)
+  var name = pkg._requested ? pkg._requested.name : pkg.name;
+  var parent = name && name[0] === '@' ? path.dirname(path.dirname(folder)) : path.dirname(folder)
   var gnm = global && opts.globalDir
   var gtop = parent === gnm

The 2.0.0 implementation changed. From my understanding it shouldn't cause any problems since the detection is done from a given installed path:

  const scopeOrNm = dirname(path)  // path should be pointing to "/path/to/node_modules/my-tape"

However, since the npm-cli still uses 1.1.6, does it make sense to create another 1.1.8 address this issue and notify npm-cli to use the new version?

When

Whenever I install a scoped package that has been aliased to use un-scoped name.

Where

node_modules/.bin directory, [email protected]

How

Current Behavior

• node_modules/.bin/tape is not created.

Steps to Reproduce

$ npm i -D my-tape@npm:@jixun/tape@^4.13.1-patch3

Expected Behavior

node_modules/.bin should contain executable for tape.

Who

• n/a

References

• n/a

SemVer major, requires node 8 and above. (While we're at it, drop support for node < 10.)

What / Why

The mkdirp-infer-owner used in https://github.com/npm/bin-links/blob/latest/lib/link-gently.js#L9 is not declared on the package.json

When

When I try to use bin-links on a folder installed by pnpm I got an error about module node found since it's not declared in the package.json

How

Current Behavior

Throw an error about the module not found

Steps to Reproduce

create a new folder
npm init -y
pnpm install bin-links
use bin-links

Expected Behavior

Should not throw an error about a module not found

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

The current bin links on Windows use a cmd, and and a ps1 script, this has a few side effects which aren't that nice to users of node on Windows:

1. When launched by the cmd launcher script, you will get the dreaded ye olde "Terminate batch job (Y/N)" prompt, which is quite annoying.
2. Scripts are not callable via ExecuteProcess, requiring a shell to execute them, which can often be a source of security vulnerabilities in the form of shell injection attacks, and is not convenient, nor consistent with the behavior on POSIX operating systems.
3. When a parent process invokes such a script and later tries to kill it via TerminateProcess, only the shell will be killed, leaving an orphaned node process, which is, again, unlike what happens on POSIX operating systems when launched via a script with a shebang.

The Python ecosystem has developed a cleaver workaround for this issues by using a launcher executable that is appended with the path to the script it should execute.

This solves the problems in the following way:

1. It is an exe, so no "Terminate batch job (Y/N)" even in cmd.
2. It is an exe, so callable via regular ExecuteProcess.
3. It establishes a job around the child so that the child is killed on TerminateProcess of the launcher.

It also includes some other handling for other edge cases/behaviors so everything is seamless.

The code for that is available here https://github.com/pypa/distlib/tree/master/PC (PSF licensed AFAIK)

Note that this effects npm (& Yarn/pnpm) itself, as well as any bin links for anything it installs.

Expected Behavior

For bin links in Windows to be as seamless as in POSIX operating system or when using Python & pip.

Steps To Reproduce

1. Hit Ctrl-C while running a script from cmd using a bin link created by this package.
2. Try to ExecuteProcess such a bin link via the PATH. E.g. fry to ExecuteProcess npm itself.
3. Launch some long running script and try to TerminateProcess on the resulting PID, the script will be left running.

Environment

• npm: 9.2.0
• Node: 16.19.0
• OS: Windows 11 x64
• platform: PC