Skip to content

fix: Allow leading forwardslash in package.json "files" field (#534)#535

Open
StevenGBrown wants to merge 1 commit into
eslint-community:masterfrom
StevenGBrown:534-forwardslash-in-published-files
Open

fix: Allow leading forwardslash in package.json "files" field (#534)#535
StevenGBrown wants to merge 1 commit into
eslint-community:masterfrom
StevenGBrown:534-forwardslash-in-published-files

Conversation

@StevenGBrown
Copy link
Copy Markdown

What is the purpose of this pull request?

Entries in the package.json "files" field that start with a forwardslash are now used by rules "n/hashbang", "n/no-top-level-await" and "n/no-unpublished-*" when determining which files are published. These entries were previously ignored by eslint-plugin-n, which prevented valid warnings from being reported.

What changes did you make? (Give an overview)

  • Background: There is code in the get-npmignore.js parseWhiteList function which adds a forwardslash to the beginning of each entry in the "files" field. This makes the pattern only apply relative to the directory containing package.json, matching the behavior of npm. Without this forwardslash, a gitignore pattern without any separators (or with only separators at the end) would match files in any subdirectory.

  • Previous behavior: For "files" entries that already started with a forwardslash, a second forwardslash would be added. The resulting pattern would not match any files.

  • New behavior: Remove any existing leading forwardslash so that we don't end up with two of them. Entries starting with a forwardslash will now match files relative to the package.json directory, as npm does.

Related Issues

Fixes #534

Is there anything you'd like reviewers to focus on?

Several different rules make use of this code but I've only updated the no-top-level-await test. Not sure its worthwhile updating all of them because we already have coverage of the changes. But let me know what you prefer?

…-community#534)

Entries in the package.json "files" field that start with a forwardslash are
now used by rules "n/hashbang", "n/no-top-level-await" and "n/no-unpublished-*"
when determining which files are published. These entries were previously
ignored by eslint-plugin-n, which prevented valid warnings from being reported.

Details:

- Background: There is code in the get-npmignore.js parseWhiteList function
  which adds a forwardslash to the beginning of each entry in the "files"
  field. This makes the pattern only apply relative to the directory containing
  package.json, matching the behavior of npm. Without this forwardslash, a
  gitignore pattern without any separators (or with only separators at the end)
  would match files in any subdirectory.

- Previous behavior: For "files" entries that already started with a
  forwardslash, a second forwardslash would be added. The resulting pattern
  would not match any files.

- New behavior: Remove any existing leading forwardslash so that we don't end
  up with two of them. Entries starting with a forwardslash will now match
  files relative to the package.json directory, as npm does.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: entry in package.json files field is ignored if it starts with a forwardslash

1 participant