-
-
Notifications
You must be signed in to change notification settings - Fork 307
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
number of tests do not match up #271
Comments
Can you make a gist with the files in question? |
I can do you one better - here is the full project https://github.com/tcurdt/xstatic |
This is how my
|
On a cloned repo, after |
Hm. That's fine. For development I've used |
Possibly - what are you linking exactly? |
@ljharb see above - all the xstatic-* modules |
That absolutely could cause issues. Closing this for now, since I can't reproduce - I don't think the |
These are separate modules. I didn't use Reproducing this should be easy. Just |
@tcurdt i may have misunderstood - you said you have |
@ljharb since the xstatic project is early stage I have all plugins and the core in one repo (like react and ember are doing it as well). The core and the plugins are all individual modules though (with own At the top level I am running some integration tests (which basically just another project linking to all the other modules). So best to forget all is in the same repo - that doesn't really matter. The
is run on the top level. Which seems to work OK with a fresh install. When I use Does that make more sense now? |
Hmm. It's likely that the |
Yes, |
OK - then since |
Not sure I can follow. You think |
@tcurdt i think that if the first "item" in one of the paths you pass to |
@ljharb but none of those are symlinks - the symlinks are only in node_modules But I am seeing even more strangeness.
works fine when called like above, now when it's part of match
it fails. WTF? Any idea? |
I'm going to reopen this for now - it would help if you made a branch on the repo that had the symlinks committed to it was easier to repro. |
This seems to be an unrelated issue - but try the following:
then try (1)
and then (2)
You will find that the test worked in (1) but fails in (2). I'll try to make the linking easily reproducible as well. |
If you run
|
wow, lots of links :-) k, i've reproduced it locally - thanks! I also see:
very weird. I'm not sure how to solve this nor why it would be happening. The fact that it requires all those links suggests it's a symlink traversal problem. |
That is possible. it would be useful to be able to repro it without blue-tape. |
Do you need to use glob's "follow" option? |
I tried that, but it didn't seem to fix the problem. |
I've just found that I'm unable to test more than one dir using glob expansion, and I think it's another indicator of this issue. For example:
Only tests from the I created a test ar glob = require("glob");
glob("./test/**/*.spec.js", function(er, files){
files.forEach(function(file){
process.stdout.write(`matched file: ${file}\r\n`);
});
}); Here's the commit from my project demoing this. I think the problem has to be related to how the results from glob are passed to tap? |
I think the problem is in the |
I'm going to create a |
Ok, definitely some odd things going on here, and I think it's because minimist is parsing the I expected the globs to be passed in, however, in each case, the glob's have already been matched. If you want, you can pull the changes in my fork into your local clone of Then, you can go to any other project you are running tests using As I continue to look into this, I wanted you guys to be able to look at what I'm seeing with these early findings. Very interesting! |
Here's another quirk. I'm running:
When I run this using |
Looks like node itself is expanding the glob's as they're assigned to Bad: Good: |
Interesting findings, @LongLiveCHIEF
|
@LongLiveCHIEF putting the globs in quotes is always a requirement, or else the shell will expand it for you. This isn't unique to @tcurdt does everything work for you if you pass the file path in quotes? |
Bug ConfirmedCauseThis bug occurs depending on whether or not your shell supports recursive globbing. By the time the values in Resolution Options
Temporary WorkaroundIn the short term, you should just be able to encase your glob's in strings in order to get the right number of tests to run. Examples: From the command line:
Or using // package.json
{
"scripts":{
"test": 'tape "./test**/*.js"'
}
}
// run using `npm test` (/cc @tcurdt ) Input NeededI'd like a project owner/maintainer to chime in on what direction they'd prefer so I know which route to go with my PR. I checked out mocha, and it looks like they get the usability without the string encasing by going with the first option. (/cc @ljharb ) |
Certainly option 2 seems simplest, and is what most command line tools require. However, I'd love to see what a PR would look like for option 1 (even though I think we should always recommend quoting path arguments in all cases). |
I think it would add about 40-60 loc to the I think option 2 is certainly easier. I thought it was fairly standard practice to support globbing without string encasing, but after digging around a bit, it's 50/50. If we go with option 2, I think we should update the README to mimic the [eslint.org cli-usage docs](http://eslint.org/docs/user-guide/command-line-interface homepage, up through the part where it says:
|
Looks like all this time, the Usage section of the README.md had us covered. @tcurdt can you confirm that encasing your glob's as strings solves your problem, and then we can close? |
@ljharb I changed the setup and get by without the linking - and with that all works as is. |
Can I ask... why are you using |
@LongLiveCHIEF could that be a problem? I guess that's a leftover from the npm setup where I use it with istanbul
|
I don't think that should be a problem. However, they definitely need to be quoted. I think I'm going to close this for now. If someone wants to try a PR that makes unquoted options work, that'd be very interesting to consider. |
and
115 != 204
WTF?The text was updated successfully, but these errors were encountered: