Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 15 08:25
    depfu[bot] labeled #786
  • Jan 15 08:25
    depfu[bot] opened #786
  • Jan 15 07:20

    depfu[bot] on update

    Update karma to version 6.0.0 (compare)

  • Jan 04 21:27
    papandreou review_requested #785
  • Jan 04 21:27
    papandreou review_requested #785
  • Jan 04 19:31
    papandreou synchronize #785
  • Jan 04 19:31

    papandreou on childInheritsFromParentExpect

    Prevent test from bleeding into… (compare)

  • Jan 04 19:21
    papandreou opened #785
  • Jan 04 19:21
    papandreou assigned #785
  • Jan 04 19:18

    papandreou on childInheritsFromParentExpect

    Make a child expect's prototype… Hmm, why shouldn't child expect… (compare)

  • Jan 04 16:58

    papandreou on master

    Don't prohibit expect.outputFor… (compare)

  • Jan 04 16:52
    papandreou commented #784
  • Jan 04 14:08
    alexjeffburke commented #784
  • Jan 03 11:01
    papandreou labeled #784
  • Dec 24 2020 13:27
    papandreou edited #784
  • Dec 24 2020 13:25
    papandreou edited #784
  • Dec 24 2020 13:19
    papandreou edited #784
  • Dec 24 2020 13:19
    papandreou edited #784
  • Dec 24 2020 13:18
    papandreou edited #784
  • Dec 24 2020 13:15
    papandreou edited #784
Andreas Lind
@papandreou
Thanks for bringing it up :)
Christopher Hiller
@boneskull
breaking everybody sucks, don’t do it
I feel like the value of using “to satisfy” with an empty object is pretty low.
perhaps changing that would be acceptable. if you write expect({foo: ‘bar’}, ‘to satisfy’, {}) you should use ’to be an object’ instead or something.
Andreas Lind
@papandreou
This super naive hack only breaks 11 tests in core, mostly in error messages where plainObject shows up instead of object, and some stuff with the obscure arguments type:
diff --git a/lib/assertions.js b/lib/assertions.js
index 47905ce9..14850862 100644
--- a/lib/assertions.js
+++ b/lib/assertions.js
@@ -1437,7 +1437,7 @@ module.exports = (expect) => {
   );

   expect.addAssertion(
-    '<Error> to [exhaustively] satisfy <object>',
+    '<Error> to [exhaustively] satisfy <plainObject>',
     (expect, subject, value) => {
       const valueType = expect.argTypes[0];
       const subjectKeys = expect.subjectType.getKeys(subject);
diff --git a/lib/createTopLevelExpect.js b/lib/createTopLevelExpect.js
index 6b79f498..fc76f695 100644
--- a/lib/createTopLevelExpect.js
+++ b/lib/createTopLevelExpect.js
@@ -1720,7 +1720,11 @@ expectPrototype.standardErrorMessage = function (output, options) {

   if (options && options.compact) {
     options.compactSubject = (output) => {
-      output.jsFunctionName(this.subjectType.name);
+      let typeName = this.subjectType.name;
+      if (typeName === 'plainObject') {
+        typeName = 'object';
+      }
+      output.jsFunctionName(typeName);
     };
   }
   return createStandardErrorMessage(
diff --git a/lib/types.js b/lib/types.js
index b00bdecb..25371251 100644
--- a/lib/types.js
+++ b/lib/types.js
@@ -897,6 +897,17 @@ module.exports = function (expect) {
     },
   });

+  expect.addType({
+    base: 'object',
+    name: 'plainObject',
+    identify(obj) {
+      return (
+        this.baseType.identify(obj) &&
+        Object.getPrototypeOf(obj) === Object.prototype
+      );
+    },
+  });
+
   expect.addType({
     base: 'object',
     name: 'function',
Christopher Hiller
@boneskull
idk. it’s worth considering because this sort of thing can lead to false positives, and false positives (imo) are worth breaking things to avoid
Andreas Lind
@papandreou
Yeah, exactly.
Let's see what the others think. I'm on my way to bed, talk to you later :)
Christopher Hiller
@boneskull
I only hit this problem because I had a function which used to return a Set, and now it returns an object, and my test was passing and it shouldn’t have been
tty, good night!
Andreas Lind
@papandreou

Simpler and less invasive fix:

diff --git a/lib/assertions.js b/lib/assertions.js
index 47905ce9..63bef536 100644
--- a/lib/assertions.js
+++ b/lib/assertions.js
@@ -1949,6 +1949,9 @@ module.exports = (expect) => {
       if (valueType.is('array-like') && !subjectIsArrayLike) {
         expect.fail();
       }
+      if (Object.getPrototypeOf(value) !== Object.prototype) {
+        expect.fail();
+      }

       const subjectKeys = subjectType.getKeys(subject);
       const valueKeys = valueType.getKeys(value);

That doesn't make any current tests fail. If you want <object> to satisfy <some more specific type> you should probably create a more specific assertion anyway.

@boneskull, so that function that now returns a Set was used to retrieve the RHS of the to satisfy assertion in the test suite? I'm usually very conservative with too much complexity in tests, preferring to always assert against constants. But people have different styles :)
Andreas Lind
@papandreou
Let's see what :bird: has to say: unexpectedjs/unexpected#781
Andreas Lind
@papandreou
There's 5 failing u-messy tests, but everything else works: https://github.com/unexpectedjs/unexpected/pull/781/checks?check_run_id=1541877571
Andreas Lind
@papandreou
Fixed that in u-messy 10.0.1, :bird: passes now.
Peter Müller
@Munter
Happy birthday @papandreou 🥳🎉
Andreas Lind
@papandreou
Thanks, Peter! :green_heart:
Sune Simonsen
@sunesimonsen
Happy b-day @papandreou 💚
Andreas Lind
@papandreou
Thanks!
Alex J Burke
@alexjeffburke
re unexpectedjs/unexpected#781 - that handles one case, but just noting that we still have the issue the other way round. Namely, if you refactored some code and changed the subject from an {} to a new Map(), you will have weird results because the properties attached to the Map object will be checked rather than the .set() mappings it contains
perhaps that's a vote for having Map in core so that just can't happen - to answer your Q @papandreou, I think the plugin is actually in a good state as it stands - I did a pretty extensive rework leading up to v2 that ported all the v11 "to satisfy" behaviours
Andreas Lind
@papandreou
Then now might be the time to onboard it :)
Sune Simonsen
@sunesimonsen
🤠
Andreas Lind
@papandreou
@alexjeffburke, yeah, you’re right about that. Whether or not we pull in u-set or u-map it might make sense to similarly assert that the subject isn’t a Map/Set/WeakMap/WeakSet instance — as it’s very unlikely to assert what you want.
Alex J Burke
@alexjeffburke
@papandreou was thinking along similar lines
Andreas Lind
@papandreou
We can fold that into the PR, should probably also be semver-major
Andreas Lind
@papandreou
Done
Andreas Lind
@papandreou
I've played around with camelCase assertion syntax in core: unexpectedjs/unexpected#784
It's a super inefficient implementation for now, but LMK if there's appetite for getting something like this in, or if you have feedback about the syntax or feature set.
I hope we'd be able to use the type generation part of unassessed on top :)
Sune Simonsen
@sunesimonsen
Marry Christmas ❤️🎄
Andreas Lind
@papandreou
Merry Christmas! 🤗
Gert Sønderby
@gertsonderby
Glædelig Jul.
Sune Simonsen
@sunesimonsen
Happy New Year 💥💫🔥
Andreas Lind
@papandreou
Happy New Year! :tada: :wine_glass:
Alex J Burke
@alexjeffburke
Same wish from me, have a nice start everyone :)
Peter Müller
@Munter
Happy new year! Here's to 2021 being better than 2020
Gustav Nikolaj
@gustavnikolaj
Happy new year everyone :) And welcome back to the home office
Andreas Lind
@papandreou
Here we are again :weary: :smile_cat:
Sune Simonsen
@sunesimonsen
Funny right from the morning @gustavnikolaj 😅
@papandreou sorry for not looking at your camel case spike yet, I'm in Svendborg until Wednesday, but I'll take a look when I have some time.
Andreas Lind
@papandreou
No rush at all! There's still plenty of stuff to fix on it. It would be nice to get some feedback on the api when you have time, you can just ignore everything except the new test: https://github.com/unexpectedjs/unexpected/pull/784/files#diff-d03ea72142f3971d3a3e4ff1b79deedba7269b7530be66d24150ab4f20520473R1
Sune Simonsen
@sunesimonsen
Will do.
Andreas Lind
@papandreou
Thanks
Gustav Nikolaj
@gustavnikolaj
By default mocha looks for test files in ./test/*.js, and with the --recursive option it will use the equivalent of ./test/**/*.js. I'd like to change that to **/test/*.js and ideally through configuration. I cannot find anything about it in the docs nor on the website. Do you have any clue about how to do that?
Gustav Nikolaj
@gustavnikolaj
Figured it out. You can use a spec-key in your config object and make it a list of globs. :)
Andreas Lind
@papandreou
:heavy_check_mark:
Peter Müller
@Munter
There's a lot of docs that need to be updated to the more modern takes that mocha has now
Config files in jason/yaml, async functions for tests instead of done callbacks etc
Gustav Nikolaj
@gustavnikolaj
I need to build a static site, but one with translated content --- and urls. Are you aware of any tools handling things like that?