Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Files named "*" are excluded from npm release #1048

Closed
gauntface opened this issue Mar 23, 2020 · 6 comments
Closed

[BUG] Files named "*" are excluded from npm release #1048

gauntface opened this issue Mar 23, 2020 · 6 comments

Comments

@gauntface
Copy link

What / Why

I have a package where I'd like to have a CSS file names *.css.

When running npm pack, the file is not included

When

Consistently every time.

Where

npm public registry

Steps to Reproduce

  1. Create an npm package
  2. Add a file named *.css
  3. Run npm pack to build package
  4. Explore the package and see that *.css is exlcuded

Expected Behavior

*.css should be included

Who

  • n/a

References

  • n/a
@DanielRuf
Copy link

*.css should be included

I do not understand your use case. Why do you use a * (which is a glob pattern, and also an invalid file on Windows for example) for a file?

npm-packlist does the work to create a tar file, see

cli/lib/pack.js

Lines 154 to 159 in d5dfe57

return BB.resolve(packlist({ path: dir }))
// NOTE: node-tar does some Magic Stuff depending on prefixes for files
// specifically with @ signs, so we just neutralize that one
// and any such future "features" by prepending `./`
.then((files) => tar.create(tarOpt, files.map((f) => `./${f}`)))
.then(() => getContents(pkg, tmpTarget, filename, logIt))

cli/lib/pack.js

Lines 177 to 182 in d5dfe57

log.notice('=== Tarball Contents ===')
if (tarball.files.length) {
log.notice('', columnify(tarball.files.map((f) => {
const bytes = byteSize(f.size)
return {path: f.path, size: `${bytes.value}${bytes.unit}`}
}), {

https://www.npmjs.com/package/npm-packlist

This uses the following rules:

  1. Unless they're explicitly included (by being in a files list, or a !negated rule in a relevant .npmignore or .gitignore), always ignore certain common cruft files:
    2. editor junk like .*.swp, ._* and .*.orig files

@DanielRuf
Copy link

https://github.com/npm/npm-packlist/blob/d5dfe57a1d810fe7fd64edefc976633ee3a4da53/index.js#L65-L66

// There may be others, but :?|<> are handled by node-tar
const nameIsBadForWindows = file => /\*/.test(file)
/\*/.test('asdasd')
false
/\*/.test('*.test')
true
/\*/.test('*.css')
true

https://github.com/npm/npm-packlist/blob/d5dfe57a1d810fe7fd64edefc976633ee3a4da53/index.js#L324-L332

  // override parent stat function to completely skip any filenames
  // that will break windows entirely.
  // XXX(isaacs) Next major version should make this an error instead.
  stat (entry, file, dir, then) {
    if (nameIsBadForWindows(entry))
      then()
    else
      super.stat(entry, file, dir, then)
  }

So this is not a bug but intended.

@DanielRuf
Copy link

Not sure if the files list works but I would recommend to avoid files like *.css which might cause issues on Windows.

You can explicitly re-include any of these with a files list in package.json or a negated ignore file rule.

@gauntface
Copy link
Author

Feel free to close if it's something that will break on Windows. I largely used Linux so I doubt I would have caught that.

Use case is a somewhat unusual tool I've been writing where css and js injected into a page based on HTML in the page and I wanted to use the css class '*'.

To get around this issue I've just used a different magical character.

@DanielRuf
Copy link

Use case is a somewhat unusual tool I've been writing where css and js injected into a page based on HTML in the page and I wanted to use the css class '*'

In CSS * alone selects all elements which is discouraged.
Ok so these are some placeholders in your case?

Yes, I'd say this is an unusual use case, at least for me.

@isaacs
Copy link
Contributor

isaacs commented Jun 2, 2020

Yeah, using a different magical character is the approach I'd use.

If you do want your tool to depend on * characters in filenames, and you don't care about Windows support, then you can of course create these files in your test setup or ship them a different way. You just can't publish them in an npm package, because it breaks downstream users.

Sorry for the inconvenience. I don't like it either. In a perfect world, Windows would have moved to a fully posix compliant file system long ago.

@isaacs isaacs closed this as completed Jun 2, 2020
maxwellgerber added a commit to maxwellgerber/cli that referenced this issue Jun 2, 2020
In npm/npm-packlist#32, NPM started to drop filenames containing the `*` character.

See:
- npm#1096
- npm#1048
claudiahdz pushed a commit that referenced this issue Jun 24, 2020
In npm/npm-packlist#32, NPM started to drop filenames containing the `*` character.

See:
- #1096
- #1048

PR-URL: #1377
Credit: @maxwellgerber
Close: #1377
Reviewed-by: @claudiahdz
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

No branches or pull requests

3 participants