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

fix CI; closes #2867 #2868

Merged
merged 5 commits into from
Jun 16, 2017
Merged

fix CI; closes #2867 #2868

merged 5 commits into from
Jun 16, 2017

Conversation

boneskull
Copy link
Contributor

I think the package-lock.json creation created by npm@5 was causing us to be unable to do npm install after an npm install --production.

@boneskull
Copy link
Contributor Author

See npm/npm#16967

@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.395% when pulling 7483f0d on issue/2867 into f20de56 on master.

@boneskull
Copy link
Contributor Author

Nope, that wasn't it. I have no idea. just gonna downgrade npm.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.395% when pulling 5db8121 on issue/2867 into f20de56 on master.

@boneskull
Copy link
Contributor Author

This may have been an incompatible "Git-style" dependency.

@boneskull boneskull changed the title obliterate package-lock.json after sanity test install; closes #2867 fix CI; closes #2867 Jun 7, 2017
@boneskull boneskull self-assigned this Jun 7, 2017
@boneskull boneskull added the qa label Jun 7, 2017
@boneskull boneskull added this to the next-minor milestone Jun 7, 2017
@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.395% when pulling 778b4b6 on issue/2867 into f20de56 on master.

@boneskull
Copy link
Contributor Author

Trying to just downgrade Node.js itself back to v7 for browser tests...

@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.395% when pulling fd326d6 on issue/2867 into 7647e18 on master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.395% when pulling c7abeca on issue/2867 into 7647e18 on master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.395% when pulling 9cdb4c2 on issue/2867 into 7647e18 on master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.395% when pulling fa0169b on issue/2867 into 7647e18 on master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.395% when pulling 8a8afc7 on issue/2867 into 7647e18 on master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.395% when pulling 31a8acf on issue/2867 into 7647e18 on master.

@boneskull
Copy link
Contributor Author

@dasilvacontin @ScottFreeCode if this goes green please merge it unless I get to it first. we should then be good to rebase the debug upgrade in branch debug onto master--at that point, it's probably worth cutting the release.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.395% when pulling 1fe4b74 on issue/2867 into 7647e18 on master.

@dasilvacontin
Copy link
Contributor

dasilvacontin commented Jun 14, 2017 via email

'karma-expect',
'karma-mocha',
'karma-spec-reporter',
require('@coderbyheart/karma-sauce-launcher')
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The plugin is named 'karma-sauce-launcher', but the package is named something else, so we have to do this. Unfortunately, if you start specifying plugins, you have to specify all of them.

@@ -320,6 +320,7 @@
"supports-color": "3.1.2"
},
"devDependencies": {
"@coderbyheart/karma-sauce-launcher": "coderbyheart/karma-sauce-launcher#5259942cd6d40090eaa13ceeef5b0b8738c7710f",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

karma-sauce-launcher was a misnomer. npm@3 and npm@4 install this anyway, but npm@5 does not; see npm/npm#17193.

I'm using the changeset SHA here to avoid pulling down any subsequent commits to master, since this is someone else's repo.

I have another branch wherein the Mocha org owns a fork, so we have complete control over how it behaves -- and what upgrades it receives.

(This was done in the first place because the original package is not-very-well maintained)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking forward to switching to our fork, although I have some questions I need to get on there and ask about that too...

@@ -9,8 +9,7 @@ var mocha = new Mocha({
growl: true
});

// mocha.reporter('spec');
require('should');
global.expect = require('expect.js');
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As noted in #2882, should is problematic for non-ES5-compliant environments, so we can't run tests using should in those environments.

jsapi runs a subset of the unit tests, which now all use expect rather than should.

return;
}

try {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this test was written in a way that assertions would still be made even if the callback received an error.

.equal(false);
});
});

describe('map()', function () {
var map = utils.map;
it('should behave same as Array.prototype.map', function () {
if (!Array.prototype.map) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this comparison isn't possible in non-ES5-compliant environments

@ScottFreeCode
Copy link
Contributor

There are a couple points where this skips tests if Object.create is absent. In one case this seems to be using Object.create as a proxy for defineProperty, which is being used to get a non-writable stack on an error to test that Mocha is able to handle those; I'd prefer to have that one check whether defineProperty is available and can create a non-writable property, but I suppose what we've got is OK since the important thing is we test this in a modern environment where that works and don't attempt it in older environments where it would blow up for lack of defineProperty. In the other case, I am not actually sure what Object.create is being checked for -- is it needed for Mocha's behavior? If so, should we be attempting to polyfill that or something instead?

Other than that, this looks fine. I mean, I'm still not sure I understand what we're fixing, but the code after the changes looks OK. And, let's face it, switching from should to expect was long overdue. 🎉

done();
});
runner.fail(test, err);
});

it('should recover if the error stack is not writable', function (done) {
if (!Object.create) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

checking for Object.defineProperty seems reasonable, but it isn't really, because IE8 implements the function incorrectly.

@@ -119,9 +125,12 @@ describe('Runner', function () {
});

it('should not fail when a new common global is introduced', function () {
if (process.browser) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test makes some assumptions about global properties that we can't guarantee across browsers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

though I think the lines here might mean this never happens.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

..no, actually, we don't want this to run in any browser, regardless if it's ES5-spec-compliant.

@boneskull
Copy link
Contributor Author

@ScottFreeCode @dasilvacontin I went thru and made a bunch of explanations. please let me know if you're still unsure about something

@boneskull
Copy link
Contributor Author

the Object.defineProperty failure in IE8 would manifest itself as an exception, I believe. it only works on DOM nodes. so it exists, but...

To be clear, I'm not just handling quirks in IE7 and IE8; PhantomJS as well.

@ScottFreeCode
Copy link
Contributor

Thanks!

Yeah, if it's going to be... complicated... to check that Object.defineProperty is not only available but correctly functioning, then we may as well just check for Object.create instead. Ideally we may want a comment in the code alluding to the issues checking for Object.defineProperty, but I'm not going to be a stickler about that.

I'm still unsure about the purpose of the other Object.create check -- the one in the checkGlobals suite I think it was.

@boneskull
Copy link
Contributor Author

@dasilvacontin Speak now or forever hold your peas

@boneskull boneskull added the semver-patch implementation requires increase of "patch" version number; "bug fixes" label Jun 15, 2017
@boneskull boneskull merged commit 50fc47d into master Jun 16, 2017
@boneskull boneskull deleted the issue/2867 branch June 16, 2017 19:33
@dasilvacontin
Copy link
Contributor

dasilvacontin commented Jun 16, 2017 via email

@boneskull boneskull removed their assignment Dec 12, 2017
sgilroy pushed a commit to TwineHealth/mocha that referenced this pull request Feb 27, 2019
* load karma plugins explicitly; closes mochajs#2867

* don't use "should" for unit tests; closes mochajs#2882

* fix some broken browser tests

* fix some problem tests in obsolete browsers

* phantomjs fixes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver-patch implementation requires increase of "patch" version number; "bug fixes"
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants