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

Config ignore/only negation not quite working properly #6907

Open
loganfsmyth opened this Issue Nov 25, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@loganfsmyth
Member

loganfsmyth commented Nov 25, 2017

I introduced negation thinking I had a working solution, but kind of questioning if that's actually the case or not :P

In the current implementation, I wanted to handle folder-level ignore/only, so you could for instance do

ignore: ["./lib"]

and to handle that I basically generated the possible folders from the filename, so if you have

lib/folder/file.js

it would test

micromatch(
  ["lib/folder/with/file.js", "lib/folder/with", "lib/folder", "lib"],
  ["lib"],
)

thereby checking if the patter matched any of the possible parents of the file.

The issue arises with negation introduced, for cases like the following

mm(
  ["lib/folder/with/file.js", "lib/folder/with", "lib/folder", "lib"],
  [
    "!lib",
    "lib/folder",
  ]
)

will match, but things like

mm(
  ["lib/folder/with/file.js", "lib/folder/with", "lib/folder", "lib"],
  [
    "lib",
    "!lib/folder",
  ]
)

will still see lib as a match, even though the folder containing the file itself was negated.

I haven't had time to think through a good solution, but I figured I'd file it so it is tracked somewhere. Maybe this is solvable by checking which items in the file/folder name list got matched?

@carlevans719

This comment has been minimized.

Show comment
Hide comment
@carlevans719

carlevans719 Feb 24, 2018

Is it possible to avoid descending into ignored directories in the first place, thus removing the need for negation? I've just found that duplicate config files in an ignored folder will cause 7.0.0-beta.40 to throw an exception so avoiding scanning the ignored directory in the altogether would possibly fix that.

edit: I've just realised that it's probably still necessary to perform the check for cases where a user does something like the following babel path/to/foo.js --ignore=path/to/foo.js

carlevans719 commented Feb 24, 2018

Is it possible to avoid descending into ignored directories in the first place, thus removing the need for negation? I've just found that duplicate config files in an ignored folder will cause 7.0.0-beta.40 to throw an exception so avoiding scanning the ignored directory in the altogether would possibly fix that.

edit: I've just realised that it's probably still necessary to perform the check for cases where a user does something like the following babel path/to/foo.js --ignore=path/to/foo.js

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment