{"action":"created","issue":{"url":"https://api.github.com/repos/jonschlinkert/glob-fs/issues/1","labels_url":"https://api.github.com/repos/jonschlinkert/glob-fs/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/jonschlinkert/glob-fs/issues/1/comments","events_url":"https://api.github.com/repos/jonschlinkert/glob-fs/issues/1/events","html_url":"https://github.com/jonschlinkert/glob-fs/issues/1","id":53226329,"number":1,"title":"wishlist","user":{"login":"jonschlinkert","id":383994,"avatar_url":"https://avatars.githubusercontent.com/u/383994?v=3","gravatar_id":"","url":"https://api.github.com/users/jonschlinkert","html_url":"https://github.com/jonschlinkert","followers_url":"https://api.github.com/users/jonschlinkert/followers","following_url":"https://api.github.com/users/jonschlinkert/following{/other_user}","gists_url":"https://api.github.com/users/jonschlinkert/gists{/gist_id}","starred_url":"https://api.github.com/users/jonschlinkert/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jonschlinkert/subscriptions","organizations_url":"https://api.github.com/users/jonschlinkert/orgs","repos_url":"https://api.github.com/users/jonschlinkert/repos","events_url":"https://api.github.com/users/jonschlinkert/events{/privacy}","received_events_url":"https://api.github.com/users/jonschlinkert/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-01-01T19:13:24Z","updated_at":"2015-01-01T22:13:07Z","closed_at":null,"body":"**Wishlist**\r\n\r\nSome user features I'd like to see in a node.js file globbing lib. Some or all of these would be nice to have:\r\n\r\n - define patterns as a string or array\r\n - allow ignore patterns to be passed on the options\r\n - ignore `node_modules` by default. IMO it makes more sense for a user to explicitly define `node_modules` to include it.\r\n - add support for specified `.ignore` files to be used via options, like `.gitignore` etc\r\n\r\n**API**\r\n\r\n- streams\r\n- async\r\n- sync\r\n\r\n**Code**\r\n\r\n- how much flexibility to we want to provide for negation patterns? \r\n- is it important to allow users to un-negate previously negated patterns? If not, things become simpler, but I don't think we'll need to compromise on speed either way"},"comment":{"url":"https://api.github.com/repos/jonschlinkert/glob-fs/issues/comments/68500133","html_url":"https://github.com/jonschlinkert/glob-fs/issues/1#issuecomment-68500133","issue_url":"https://api.github.com/repos/jonschlinkert/glob-fs/issues/1","id":68500133,"user":{"login":"jonschlinkert","id":383994,"avatar_url":"https://avatars.githubusercontent.com/u/383994?v=3","gravatar_id":"","url":"https://api.github.com/users/jonschlinkert","html_url":"https://github.com/jonschlinkert","followers_url":"https://api.github.com/users/jonschlinkert/followers","following_url":"https://api.github.com/users/jonschlinkert/following{/other_user}","gists_url":"https://api.github.com/users/jonschlinkert/gists{/gist_id}","starred_url":"https://api.github.com/users/jonschlinkert/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jonschlinkert/subscriptions","organizations_url":"https://api.github.com/users/jonschlinkert/orgs","repos_url":"https://api.github.com/users/jonschlinkert/repos","events_url":"https://api.github.com/users/jonschlinkert/events{/privacy}","received_events_url":"https://api.github.com/users/jonschlinkert/received_events","type":"User","site_admin":false},"created_at":"2015-01-01T22:13:07Z","updated_at":"2015-01-01T22:13:07Z","body":"> Why? When we could define them in string/array approach? Looks needless.\r\n\r\n1) b/c currently node-glob is a pita to use for negation, and I want to make it easier\r\n2) when implementors (versus end-users) want to define negation patterns dynamically, this offers a more convenient alternative\r\n3) explicitly defining negation patterns is faster than doing a check on every string, replacing `!` and shuffling patterns around. probably a lot faster, but it might not be noticeable since the slowest part of the operation is always going to be hitting the fs\r\n\r\n> how much flexibility to we want to provide for negation patterns? ... We have micromatch? So much as micromatch supports? ... is it important to allow users to un-negate previously negated patterns?\r\n\r\nNo, not necessarily. There are material differences in how the matching is done in micromatch and what is required for file matching. To explain:\r\n\r\nThe executive overview is that we have an opportunity to implement a strategy that either uses the matcher (micromatch/minimatch) for filtering on the fly, or that prevents building up lists of files that _shouldn't even be passed to the matcher (micromatch)_, etc. I have implemented both strategies, both work, and both are much faster than node-glob. \r\n\r\nHere is the longer version if it helps to have more detail.\r\n\r\n**micromatch**\r\n\r\nLike minimatch, micromatch has no knowledge of the file system. It's just a pattern matching tool. In other words, when you pass an array of elements to be filtered, it might be an array of files, or keywords, or anything else. micromatch just filters that array _wholesale_ based on the patterns provided. \r\n\r\n**file system globbing**\r\n\r\nThis is a different challenge. Recursing directories is slow. Regardless of how fast or slow it \"feels\" to the end-user, or whether it's sync, async or whatever... simply hitting the file system is the slowest part of the globbing operation. The point is that _we want to avoid hitting the file system whenever possible_, and in a perfect world, files and directories should be filtered on-the-fly to prevent picking up files or recursing into directories that have been negated or to only recurse into directories that match the given patterns.\r\n\r\nBy comparison, let's say you want to filter files from node_modules. node-glob will recurse all the way down and build up an array of everything in node_modules before filtering. This is a bad strategy _if we can avoid it_. It's possible to include/exclude as we go, and it's orders of magnitude faster (I'll try to do a POC for comparison). \r\n\r\nThis is all a long way of saying that:\r\n\r\n -  if the consensus is that patterns should be inclusive/exclusive in the order in which they are defined, then nothing needs to change. \r\n- However, if there is a valid necessity to allow re-inclusion of previously negated patterns (meaning \"any matching file excluded by a previous pattern will become included again\"), then that will probably effect the filtering strategy we use for recursing directories, it just depends on the details. (see the [gitignore patterns docs](http://git-scm.com/docs/gitignore#_pattern_format) for an analogy of how re-inclusion is used in the wild)\r\n\r\n"}}