Say there is a simple structure with nested dir package.json

/package
   /dir
      file.js
      file2.js
      readme.md
      package.json <- has "files": ["file.js"]
  package.json

npm-packlist it will include dir/file.js and dir/readme.me but NOT dir/package.json!

npm pack works ok: "dir/file.js, package.json, readme.md" are included, "file2.js" is not.

For a file pattern such as dist/**/!(*.test.js), the package currently adds an entry of !dist/**/!(*.test.js)/** for the ignore-walker, which results in paths such as dist/lib/x.test.js getting included in the pack. I raised the PR #29 as a possible solution, but I've since closed it because I felt it wasn't the right approach.

'use strict'

const fs = require('fs')
const path = require('path')

const mkdirp = require('mkdirp')
const rimraf = require('rimraf')
const t = require('tap')

const pack = require('../')

const pkg = path.join(__dirname, path.basename(__filename, '.js'))
t.teardown(_ => rimraf.sync(pkg))

const json = {
  name: 'test-package',
  version: '1.6.2',
  files: [
    'dist/**/!(*.test.*)'
  ]
}

const expect = [
  'package.json',
  'dist/index.d.ts',
  'dist/index.js',
  'dist/lib/util.d.ts',
  'dist/lib/util.js'
]

t.test('setup', t => {
  rimraf.sync(pkg)
  mkdirp.sync(pkg)
  fs.writeFileSync(path.join(pkg, 'package.json'), JSON.stringify(json, null, 2))

  const srcDir = path.join(pkg, 'src')
  mkdirp.sync(srcDir)
  fs.writeFileSync(path.join(srcDir, 'index.ts'), 'export const x = () => console.log("index")')
  fs.writeFileSync(path.join(srcDir, 'index.test.ts'), 'import { x } from "./index"')

  const srcLibDir = path.join(srcDir, 'lib')
  mkdirp.sync(srcLibDir)
  fs.writeFileSync(path.join(srcLibDir, 'util.ts'), 'export const y = () => console.log("util")')
  fs.writeFileSync(path.join(srcLibDir, 'util.test.ts'), 'import { y } from "./util"')

  const distDir = path.join(pkg, 'dist')
  mkdirp.sync(distDir)
  fs.writeFileSync(path.join(distDir, 'index.d.ts'), 'export declare function x(): void')
  fs.writeFileSync(path.join(distDir, 'index.js'), 'exports.x = function () { console.log("index") }')
  fs.writeFileSync(path.join(distDir, 'index.test.d.ts'), '')
  fs.writeFileSync(path.join(distDir, 'index.test.js'), 'var x = require("./index").x')

  const distLibDir = path.join(distDir, 'lib')
  mkdirp.sync(distLibDir)
  fs.writeFileSync(path.join(distLibDir, 'util.d.ts'), 'export declare function y(): void')
  fs.writeFileSync(path.join(distLibDir, 'util.js'), 'exports.y = function () { console.log("util") }')
  fs.writeFileSync(path.join(distLibDir, 'util.test.d.ts'), '')
  fs.writeFileSync(path.join(distLibDir, 'util.test.js'), 'var y = require("./util").y')

  t.end()
})

t.test('follows npm package ignoring rules', t => {
  const check = (files, t) => {
    t.same(files, expect)
    t.end()
  }

  t.test('sync', t => check(pack.sync({ path: pkg }), t))
  t.test('async', t => pack({ path: pkg }).then(files => check(files, t)))

  t.end()
})

Thanks!

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Given this:

{
  "files": [
    "lib/(!test)"
  ]
}

and a tree like this:

- lib
  - main.js
  - foo.js
  - utils
    - foo-util.js
  - test
    - main_test.js
    - foo_test.js
    - utils
      - foo-util_test.js

before the hefty refactor that happened around npm 9 (in npm-packlist), that glob would result in this:

- lib
  - main.js
  - foo.js
  - utils
    - foo-util.js

After the refactor, this is the resulting packed tree:

- lib
  - main.js

meaning the glob was ignored really (since ${main} is enforceably included).

it can be solved by changing the files array to this:

{
  "files": [
    "lib/",
    "!lib/test/"
  ]
}

which im fine with, but it does mean you've introduced a breaking change which i can't see in the changelog (could be me being blind though).

can you clarify if this is a bug or intentional? and close this if it is the latter, with an explanation if you can

Expected Behavior

glob is respected

Steps To Reproduce

N/A

Environment

• npm: 9.2.0
• Node: 19.3.0
• OS: MacOS

[email protected] is including .DS_Store files in packages at publish time. Here's a reproducible test case:

git clone https://github.com/feross/unmute-ios-audio
cd unmute-ios-audio
touch .DS_Store
npm pack

You'll see that .DS_Store is included in the pack when it should not be.

In the next major version bump, make the following change to how package.json files are handled.

For the purposes of this discussion, it is assumed to only refer to package.json manifests containing a files array. package.json files without a files list are currently ignored for the purpose of determining package contents, and will continue to be.

Current Behavior

Currently, package.json is treated as a sort of "reverse ignore" file if it has a files list. The set of rules it provides are !${x} and !${x}/** for each entry x in the files list.

Challenges of Current Behavior

For a common files list like ["index.js","lib"], this will result in an anti-ignore list of:

!index.js
!index.js/**
!lib
!lib/**

This means that a file at lib/.DS_Store will be included.

If a .npmignore or .gitignore file is present in the same directory as the package.json file, it is ignored in favor of the files list.

If a package.json file is found nested somewhere else in the tree, it is treated as an ignore file, even if it is not in a "package". (Ie, in the root or a node_modules subfolder.)

Reasoning about this interaction is particularly difficult, especially as a rule can override a previous one. Consider:

{
  "files": [
    "dist",
    "!dist/**/*.test.js",
    "dist/tests/"
  ]
}

It's not immediately obvious that a file at dist/tests/x.test.js will be included in this scenario.

Despite the complications, many users have come to depend on some of the weird edges, by simply trying things and keeping what seems to work. So, great care must be taken in any change, even a good change.

Proposal

Instead of treating package.json as a fancy ignore file, use it to hijack the readdir call in start() for the root and any folder that's a package in node_modules.

If a package.json with files exists, then resolve the globs it provides. Turn each one into a set of files in order, and if there's a !, then remove any matches from the set thus far. Then, send that to onReaddir instead of the actual results of fs.readdir. (If there's no package.json with files, then just do fs.readdir.)

What / Why

node_modules is always ignored even if it is specified in package.json's files entry, which cases node_modules in subdirectories can't be bundled with npm pack. This doesn't align with npm publish which can publish node_modules directory.

This issue only applies to npm 7, not npm 6.

When

• n/a

Where

• n/a

How

Steps to Reproduce

• Create a package.json:

  {
    "name": "some-package",
    "files": [
      "lib/node_modules",
      "other-stuff/nested"
    ]
  }

• Create the following file structure:

    .
    ├── lib
    │  └── node_modules
    └── other-stuff
       └── nested
  

• Run npm pack

Current Behavior

• lib/node_modules isn't presented in output file, while other-stuff/nested does.

Expected Behavior

• lib/node_modules should be presented in output file as well.

Who

• n/a

References

• n/a

What / Why

Was trying to figure out why pack and publish were no longer including my CHANGELOG.md file by default after I upgraded to the latest npm. Looked around for documentation and eventually discovered this was an intentional change (wouldn't mind a bit of background on that) but some of the current documentation still says it should be included by default.

Steps to Reproduce

• Search for CHANGELOG in npm-packlist README.md
• Search for CHANGELOG in https://docs.npmjs.com/cli/v8/using-npm/developers

Expected Behavior

• Docs should match actual behavior with respect to CHANGELOG and other files that are no longer included by default.

References

• Related to npm/cli#3334

If you symlink a dep that is a bundled dep, then the .git folder gets included.

cc: @ruyadorno

I got this bug recently: mahirshah/css-property-parser#21 because a filename had an asterisk in it. Evidently windows gets mad about that. I worked around the issue by renaming the files, but it seemed like the sort of thing that npm might want to raise an error about or handle somehow so that it's not an error.

What / Why

I've written a small library with CHANGELOG.md in its root folder. NPM pack it into the result, you can check that here. But npx npm-packlist does not report it:

> npx npm-packlist
index.js
package.json
index.js.map
README.md
index.ts
LICENSE.txt

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Given that I have a gitignore at the root level of my workspaces, it will supersed the .gitignore and the .npmignore at the workspace level.

This means that when I run npm publish at the level of a single package, it ends up using the root .gitignore to filter out files.

Expected Behavior

I would expect the 'ignore file resolution' order to be a such:

1. 'ws-local' .npmignore
2. 'ws-local' .gitignore
3. 'ws-root' .npmignore
4. 'ws-root' .gitignore

Steps To Reproduce

1. In this environment:

.
├── .gitignore // file content: dist
├── .npmignore // empty file
├── package.json
└── packages
    └── a
        ├── dist
        │   └── test.js
        ├── .gitignore // empty file or anything but dist
        ├── .npmignore // empty file
        └── package.json

2. With npm 8.11.0
3. Run npm publish --dry-run while cwd is packages/a
4. See that dist/test.js is not included.

Environment

• npm: 8.11.0
• Node: 16.15.0
• OS: W10/Debian(WSL)
• platform: N.A.

What / Why

npm-pack (https://docs.npmjs.com/cli-commands/pack.html) should not publish npm-shrinkwrap.json when referenced in .npmignore.

References

It's strongly discouraged for library authors to publish this file, since that would prevent end users from having control over transitive dependency updates.

http://doc.codingdict.com/npm-ref/files/shrinkwrap.html

Suggested solution

Remove row 166 ('/npm-shrinkwrap.json') from function "mustHaveFilesFromPackage".

Caused issues

When publishing libraries with Lerna with packages referring to each other, "npm install" crashes.

When npm-shrinkwrap.json is published, every package of the published library have a copy of its dependencies. In my case, the installed library takes 10 GB instead of 100MB and "npm install" crashes on some computers.

What / Why

https://github.com/npm/npm-packlist/blob/master/index.js#L34 use package glob but its not defined as dependency

Where

• n/a

How

Current Behavior

usage end with error Cannot find module 'glob'

References

https://github.com/npm/npm-packlist/blob/master/index.js#L34
https://github.com/npm/npm-packlist/blob/master/package.json#L9

What / Why

I cannot get this to ignore README.md. Am I doing something wrong?

I'm using this with npm-pack-zip (1.2.9), which installs 1.4.8 of npm-packlist.

My package.json has no files section, but I added a .npmignore file:

.git
.editorconfig
README.md
.circleci
.github
dist
node_modules
.tool-versions

Adding *.md also does nothing. There is a .gitignore but it does not mention (include) README.md or any other .md file.

Where

• Npm 7.6.3
• Node 15.12.0
• npm-packlist 1.4.8

Current Behavior

README.md is not excluded

Expected Behavior

README.md should be excluded

It would be useful to see the list of packages without running npm pack.

I.E. being able to run npx npm-packlist

Right now most of my packages requires me to add .npmignore because I can't add everything to te gitignore.

But because of this I notice that this package either uses npmignore or gitignore so I see myself in a position of duplicating most of the content of my gitignore into my npmignore but except the files that I actually want to keep.

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

bundledDependencies does not work when using NPM's new workspaces feature.

The node_modules folder is no longer in the subpackage, only in the root package, so the bundledDependencies field no longer works.

Expected Behavior

Running npm pack --workspaces should pack bundledDependencies stored in my subpackage's package.json file.

Steps To Reproduce

Create a new folder and run the following to generate a package.json and a subpackage/package.json file.

npm init -f && npm init -f -w subpackage

Then add the following lines to both package.json and subpackage/package.json:

"dependencies": {"tar": "*"},
"bundledDependencies": ["tar"],

Then, do an npm install && npm pack --workspaces. You should see that npm pack correctly has a === Bundled Dependencies === line, while npm pack --workspaces does not.

Environment

• npm: 8.10.0
• Node: v16.13.0
• OS: Ubuntu 22.04
• platform: Intel x86_64 processor: i7-1165G7

According to

Greetings,

The Pull-Request n°8 got one of our Lerna projects broken due to a folder named "/lib/core" being missing on the NPM registry.

After some debugging, I have tracked the origin of the missing folder to the aforementioned PR.
The missing folder has nothing to do with a Linux core dump but instead contains the core components of the private tool we are hosting on NPM.

For the time being, we worked around the issue by adding !/lib/core in the local folder of the tool so that it overrides the default blacklist.

An option to disable that behavior would be nice as mentioned in the PR itself: #8 (comment)

It's a reasonable assumption that an NPM module will contain file assets - some of which may match the names of files desired to be excluded at the root module level. In this case, we will focus on package-lock.json

Small example:

mkdir test
cd test
npm init
mkdir files
cd files
touch package-lock.json
touch a-file.txt

At this point in time, we have the following structure:

-test
--package.json
--files
---a-file.txt
---package-lock.json

Now back on the cli... Get back into the root 'test' and pack...

cd ..
npm pack

In our resulting test-1.0.0.tgz, './files/package-lock.json' has been excluded... In the purpose of this NPM module, all things living under 'files' are merely assets for my module - and is not intended to serve as a npm package lock file, as it's merely a project asset...

The real world scenario that gave rise to this is in an Angular Schematics project I've been working on. Often times, Schematics are created to write files out to an Angular project - files in my case that include a package-lock.json... After a bug was reported about the application no longer being able to build on new machines, I began researching the Schematic dist and confirmed that it did in fact include the package-lock.json.. I then noticed that the tgz resulting from 'npm pack' did not have this nested package-lock.json. Disclaimer: I've read about shrinkwrap, but figured that the argument of 'package-lock.json as an asset' was still legitimate.

Thanks!

package-lock.json at the root should never be included in tarballs, even if specified in files. Right now, it's possible to do so if the file is referred to by files.

How

See https://github.com/coreyfarrell/pack-socket for demonstration

Current Behavior

If a unix socket file has a filename that would be included in npm pack it is not ignored. This causes a cb() never called! error.

Steps to Reproduce

On Linux (or maybe OSX):

git clone https://github.com/coreyfarrell/pack-socket
cd pack-socket
npm pack

Expected Behavior

Unix socket files should be ignored regardless of .npmignore / package.json#files settings

What / Why

You added a require('npm-normalize-package-bin')

https://github.com/npm/npm-packlist/blob/master/index.js#L20

the package npm-normalize-package-bin is not in the package.json, consumers will not have it.

In npm.community#6140 someone wants to have a package.json in a template/ folder, pretty reasonable stuff. However, the package.json has a files field which, in their use case, should be ignored when packing/publishing the parent package. There is a specific test case for the current behavior, but I was wondering if onPackageJson was originally intended for all nested package.jsons, or just those in bundleDependencies.

I have a package.json file with a "files" section and "bundleDependencies". I use this to package everything that I need for "production" which excludes e.g. some tests. With v1.4.6 this works. It stopped working with v2.0.0 and still does not work with v2.0.1.

I added the following test to my clone of npm-packlist to demonstrate the problem. If I alter the test so the package.json does not have "files" then it packages bundleDependencies.

From 8594de0245c5a33571599649abcf42c728f29bbf Mon Sep 17 00:00:00 2001
From: Thomas Sondergaard <[email protected]>
Date: Tue, 26 Nov 2019 20:19:23 +0100
Subject: [PATCH] Add failing test for package.json with "files" and
 "bundleDependencies"

---
 ...age-json-files-with-bundled.js-TAP.test.js | 20 +++++++++++
 test/package-json-files-with-bundled.js       | 36 +++++++++++++++++++
 2 files changed, 56 insertions(+)
 create mode 100644 tap-snapshots/test-package-json-files-with-bundled.js-TAP.test.js
 create mode 100644 test/package-json-files-with-bundled.js

diff --git a/tap-snapshots/test-package-json-files-with-bundled.js-TAP.test.js b/tap-snapshots/test-package-json-files-with-bundled.js-TAP.test.js
new file mode 100644
index 0000000..1e4e562
--- /dev/null
+++ b/tap-snapshots/test-package-json-files-with-bundled.js-TAP.test.js
@@ -0,0 +1,20 @@
+/* IMPORTANT
+ * This snapshot file is auto-generated, but designed for humans.
+ * It should be checked into source control and tracked carefully.
+ * Re-generate by setting TAP_SNAPSHOT=1 and running tests.
+ * Make sure to inspect the output below.  Do not ignore changes!
+ */
+'use strict'
+exports[`test/package-json-files-with-bundled.js TAP package with files and bundledDependencies > expect resolving Promise 1`] = `
+Array [
+  "lib/one.js",
+  "package.json",
+]
+`
+
+exports[`test/package-json-files-with-bundled.js TAP package with files and bundledDependencies > must match snapshot 1`] = `
+Array [
+  "lib/one.js",
+  "package.json",
+]
+`
diff --git a/test/package-json-files-with-bundled.js b/test/package-json-files-with-bundled.js
new file mode 100644
index 0000000..7f27843
--- /dev/null
+++ b/test/package-json-files-with-bundled.js
@@ -0,0 +1,36 @@
+const t = require('tap')
+
+const elfJS = `
+module.exports = elf =>
+  console.log("i'm a elf")
+`
+
+const pkg = t.testdir({
+  'package.json': JSON.stringify({
+    xfiles: [
+      '/lib/one.js',
+    ],
+    'bundleDependencies': [
+      'history'
+    ]
+  }),
+  lib: {
+    'one.js': 'one',
+  },
+  node_modules: {
+      history: {
+        'package.json': JSON.stringify({
+          name: '@npmwombat/history',
+            version: '1.0.0',
+          main: 'index.js'
+        }),
+        'index.js': elfJS,
+      }
+    }
+})
+
+const packlist = require('../')
+t.test('package with files and bundledDependencies', async t => {
+  t.matchSnapshot(packlist.sync({path: pkg}))
+  await t.resolveMatchSnapshot(packlist({path: pkg}))
+})
-- 
2.21.0

The major version of this package was bumped recently but I couldn't find any release notes indicating what the potentially breaking changes were.

From skimming recent issues it looks like #39 was the only reason for this?

Is there anything that consumers of the package should watch out for?

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

See repro steps.

Expected Behavior

See repro steps.

Steps To Reproduce

1. Clone https://github.com/ljharb/list-exports
2. npm install
3. cd packages/tests/fixtures/single-spa-layout/project
4. run this code:

const packageDir = process.cwd();
const packlist = require('npm-packlist');
const Arborist = require('@npmcli/arborist');
const arborist = new Arborist({ path: packageDir });
const arbTree = await arborist.loadActual();
const packedFiles = await packlist(arbTree, { path: packageDir });

1. observe how packedFiles has three node_modules files in it; it should have none.
2. if you rm -rf node_modules, then packedFiles will no longer contain those three files, but since they're not there anymore, that's expected.

Environment

• npm: 10.2.5
• Node: 21.4.0
• OS: Mac
• platform: Macbook Pro

.git files are a standard feature of git: https://git-scm.com/docs/gitrepository-layout

npm-packlist ignores.git folders, but not .git files:

yarn pack ignores .git files as expected, and I think npm should, too.

This is arguably a minor privacy/security issue, since the .git file contains a local file path.

Hello,
I have a question regarding the standard usage of npm-packlist.
In the readme this example is mentioned:

...
const arborist = new Arborist({ path: packageDir })
arborist.loadActual().then((tree) => {
  packlist(tree)
...

For a monorepo using pnpm and ^workspace protocol, the operation of finding missing edges (using loadActual without specifying ignoreMissing set to true) can take a lot of time. I guess it's because of pnpm symlinks where loadActual will try to scan a lot of node_modules. My goal is only to pack the package as it is without further changes.
My question: What is the impact of changing ignoreMissing to true ?
Thank you,

One weird trick that might be useful: https://twitter.com/isntitvacant/status/1131094910923231232?s=21

Hello,

As described in this npm issue, not only the root-level ./node_modules directory is being ignored, but any other directories called node_modules, for example ./lib/node_modules or ./src/node_modules or ./a/b/c/node_modules.

The readme file here mentions Everything in the root node_modules is ignored, and says nothing about other node_modules directories, so I assume the intention might have been to ignore only the root-level one.

So, what is the expected behavior? To ignore only the root-level node_modules, or any?

Thank you.

What / Why

A large population of npm users are concerned about package sizes and with the advent of the file explorer now available on the npmjs.com website we can now see a number of common files that are very intrinsic to the JS community that we could start ignoring from package bundles without too much friction to the larger ecosystem.

Being a breaking change if we are to do it, we should bring this in time for npm@7

How

Expand the current list of ignored files to also ignore by default:

• .editorconfig
• .gitattributes
• .idea (folders and more editors similar configs/store)
• .travis.yml (and/or more ci services)
• .yo-rc.json

...and whatever more we think makes sense

Who

• @npm/cli-team

References

• n/a

What / Why

Node.js added a new exports property to package.json in v12.7.0 to define entry-points.

Since these files are definitely needed in the package, I'd like for files in the exports map be automatically added as well.

When

Whenever I define entry assets in the exports map for published packages.

Where

Any npm package

How

Current Behavior

Currently, npm-packlist automatically detects important files via package.json properties browser, main, and bin.

Expected Behavior

For files in the exports property to be automatically added too.

I'm not sure if the exports map is only respected by Node if "type": "module" is set, but if it is, it should conditionally only add the exports map given "type": "module".

This might be a dangerous change in case the exports property is used by some packages for something else, but checking the type will alleviate the risk a little bit. Might be worth a breaking change.

Who

• n/a

References

• n/a

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Running npm pack includes the previous result of npm pack by default.

Expected Behavior

The result of npm pack is excluded. This probably means all .tgz files should be excluded. Users can choose to exclude it, but many don’t know about it.

Steps To Reproduce

1. Clone a repo that doesn’t use the files fields in package.json and doesn’t use .npmignore to exclude .tgz files. For example:

   [email protected]:postcss/postcss.git
   cd postcss

2. Packing produces the expected results:

   npm pack

3. Packing again includes the previously built tarball

   npm pack

Environment

• npm: v20.5.1
• Node: 9.8.1
• OS: Pop!_OS 22.04
• platform: System76 Oryx Pro

What / Why

See this example package.json:

{
  "name": "some-package",
  "version": "0.0.1",
  "main": "mymain.js",
  "files": [
    "some-file-i-want-to-include.js",
    "some-other-file.js"
  ],
  "types": "mymain.d.ts"
  ...
}

When running npm pack the types property is ignored. This means the file mymain.d.ts is not included in the tar.

How

Current Behavior

The main file mymain.js is automatically included when using npm-packlist. The types file will not be included. This is not expected behaviour. I expect the types file to be included regardless of the ocurrence in the files array.

Steps to Reproduce

Take any package.json with a files array, add a types property and run npm pack.

Expected Behavior

I would expect the types/typings property to have higher priority than the files property. The main property already has this behaviour.

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Official npm docs (here) recommend using npx npm-packlist.

To see what will be included in your package, run npx npm-packlist.

I believe that feature was broken in #128 with the removal of the "bin" property from "package.json".

Current behavior is:

$ npx npm-packlist
npm ERR! could not determine executable to run

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/username/.npm/_logs/2023-03-19T00_30_14_201Z-debug-0.log

@nlf noted in the PR that "the npm-packlist bin has also been removed." but did not explain why.

Expected Behavior

npx npm-packlist should a list of files that will be included during npm publish.

Steps To Reproduce

1. In a repo of a project that is ready to be published to npm
2. Execute on the command line npx npm-packlist

Environment

• npm: 8.19.3
• Node: 18.13.0
• OS: macOS 13.2.1
• platform: Macbook Pro
• iTerm2
• zsh

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

foo/**/* matches nothing.

Expected Behavior

foo/**/* recursively matches all files and directories under the directory foo/.

Steps To Reproduce

I modified the test test/package-json-directory-glob.js (danpere/npm-packlist@43c6d5d) to display the behavior:

1. Checkout the branch bug/star-star-slash-star from my fork danpere/npm-packlist.
2. Run npm test.
3. Observe that the test fails.
4. Checkout the branch bug/star-star-slash-star-revert-205 from my fork danpere/npm-packlist, which differs only in that I ran git revert cd5ddbd9fc7069d62fd89e0de741523e408c889b to revert #205.
5. Run npm test.
6. Observe that the test passes.

Environment

• npm: 10.2.5
• Node: 20.10.0
• OS: Windows 11 Enterprise Version 10.0.22631 Build 22631
• platform: Surface Book 2

When the "main" field in package.json is set to index instead of index.js it will attempt to include all files called index in the tarball when running npm pack

This includes .git/index which includes the .git directory which makes npm fail with EISGIT at installation time ( not publish time ).

We do not want to publish .git because that poisons the tarball.

Steps to reproduce :

• edit package.json "main" to index instead of index.js ( can be in npm-packlist )
• run npm pack --dry-run
• verify that .git/index is printed on STDOUT

Hello!

I hope you are doing well!

We are a security research team. Our tool automatically detected a vulnerability in this repository. We want to disclose it responsibly. GitHub has a feature called Private vulnerability reporting, which enables security research to privately disclose a vulnerability. Unfortunately, it is not enabled for this repository.

Can you enable it, so that we can report it?

Thanks in advance!

PS: you can read about how to enable private vulnerability reporting here: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository