Comments (6)
I noticed that the docs say:
- Exactly according to gitignore man page, fixes some known matching issues of fstream-ignore, such as:
- '
/*.js
' should only match 'a.js
', but not 'abc/a.js
'.- '
**/foo
' should match 'foo
' anywhere.- Prevent re-including a file if a parent directory of that file is excluded.
- Handle trailing whitespaces:
'a '
(one space) should not match'a '
(two spaces).'a \ '
matches'a '
- All test cases are verified with the result of
git check-ignore
.
That's great and everything about better accuracy for .gitignore files. Perhaps NPM deviates somewhat from this standard, by using fstream-ignore
. But is there an option to simulate NPM's behavior?
If not, please document more clearly that this library is useless with .npmignore
files, because I just wasted an hour trying to debug why there are weird inaccuracies in the selection results. :-)
from node-ignore.
.npmignore
does NOT follow the gitignore rules.
fstream-ignore
depends on minimatch
which basicly follows fnmatch(3) and its specific rules.
So the answer is NO (, it is not possible).
PS: I suggest to always use field package.json.files
instead of .npmignore, because we only know which files should be included in the npm tarball
from node-ignore.
Would you consider implementing support for NPM rules as an option? Maybe it is not a difficult enhancement to make.
Alternatively, perhaps the README.md could have a disclaimer making this limitation more clear?
from node-ignore.
PS: I suggest to always use field
package.json.files
instead of .npmignore, because we only know which files should be included in the npm tarball
This problem is easily solved by inverting the ignore expressions. Our files generally look like this:
# Ignore everything by default
**
# Use negative patterns to bring back the specific things we want to publish
!/bin/**
!/lib/**
!/dist/**
This same solution also works for other files like .prettierignore
and .eslintignore
, since they were also mistakenly designed as "ignore" lists instead of "include" lists.
The package.json files
setting is NOT a good approach. It has a couple downsides:
- Adding project settings to package.json makes that file larger, which hurts installation performance. The NPM registry REST protocol inexplicably transmits the full package.json contents for every historical version of a package. During installation, this HTTP GET frequently has a larger payload than the actual tarball being installed.
- You cannot put code comments in the JSON file. Code comments are a pretty important requirement for a professional scenario such as package publishing.
from node-ignore.
Would you consider implementing support for NPM rules as an option? Maybe it is not a difficult enhancement to make.
If you read the .gitignore spec carefully, you will figure out that npmignore is completely a different story. For npmignore, you could use minimatch (for just pattern parsing) or fstream-ignore (with file system)
Alternatively, perhaps the README.md could have a disclaimer making this limitation more clear?
Yes
from node-ignore.
👍 Thanks!
from node-ignore.
Related Issues (20)
- Options merge HOT 4
- Suggested replacement for addIgnoreFile doesn't work always HOT 4
- Clarify "unignored" result of "test" method HOT 9
- How to check if the working directory should be ignored? HOT 1
- TypeScript: add support for `readonly string[]`
- Negate broken HOT 1
- [Feature] Add export field or new package to render real world gitignore? HOT 2
- [Feature] npm exec script HOT 1
- wrong result for node_modules HOT 2
- directory ending with / not always correctly ignored HOT 7
- Find out which paths to watch HOT 4
- Negative pattern ignored when inside a subdirectory HOT 2
- Negated directory inclusion fails with glob HOT 1
- Trailing backslash in the ignore file is throwing a syntax error. HOT 1
- \# does not work HOT 1
- Pathname should be a path.relative()d pathname Error with ../ path HOT 2
- Add support for OR syntax `{js,ts}` HOT 3
- foo/* not correctly respected HOT 4
- "*.app" ignores "Notificator.app/Contents/PkgInfo" HOT 2
- Typescript support for moduleResolution node16 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from node-ignore.