When running in strict mode within a context with deep-frozen primordials, things like Object.keys cannot be modified. This is the situation when running in Secure EcmaScript (SES) containers

in lib/keys.js

exports = module.exports = typeof Object.keys === 'function'
  ? Object.keys : shim;

exports.shim = shim;
function shim (obj) {
  var keys = [];
  for (var key in obj) keys.push(key);
  return keys;
}

if Obect.keys is present, it will have shim appended to it. if Object.keys is frozen, this will throw an Error.

node -p "'use strict'; Object.freeze(Object.keys); Object.keys.shim = () => {};"                 
[eval]:1
'use strict'; Object.freeze(Object.keys); Object.keys.shim = () => {};
                                                           ^

TypeError: Cannot add property shim, object is not extensible
    at [eval]:1:60
    at Script.runInThisContext (vm.js:122:20)
    at Object.runInThisContext (vm.js:329:38)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (internal/modules/cjs/loader.js:776:30)
    at evalScript (internal/bootstrap/node.js:589:27)
    at startup (internal/bootstrap/node.js:265:9)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

https://github.com/nodejs/LTS/wiki/Breaking-changes-between-v0.12-and-next-LTS-release#assert-check-object-prototype-in-assertdeepequal

nodejs/node#621

This changes the method semantics so it should be a major version bump like node did probably.

Will address mjackson/expect#17

Issue

I'm using the expect package from npm, which uses this package under the hood to check for deep equality. In my eyes, the test below should fail (different values and different references), but it is passing:

it('should fail', () => {
  const actual = new Set('a');
  const expected = new Set('b');
  expect(actual).toEqual(expected);
});

If I did something like this with another collection (like arrays), the test wouldn't pass until 1) the references are the same with assert.equal / , expect.toBe or 2) the values are the same with assert.deepEqual / expect.toEqual

Background

I'm using Babel 5 to use Set. I'm using Node 5, so the Set being used should be native.
Am I doing something wrong, or does this look like a bug in the expect package in the way it handles Sets? I've cross posted a Stack Overflow question as I'm not sure.

I originally posted this on the expect package issues, but they sent me here, since that package uses this package ;)
mjackson/expect#47 (comment)

cc: @mjackson, @rstacruz

deepEqual(
    [1,2,3],
    (function () { return arguments; })(1,2,3)
);
// true

The arguments comparison will only work if isArguments(actual). If it isn't, then expected is never tested as arguments.

Also, you should remove return deepEqual(a, b, opts); from line 47. All the previous checks will still be valid the second time around and the only part that matters is after this return. It just adds extra processing time.

Also, I would like to see equality checking for Buffers. It is in assert.deepEqual, I think it should be here too.

The devDependency eslint was updated from 6.6.0 to 6.7.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Node version: 15.14.0
deep-equal version: 2.0.5

Test:

❯ node
Welcome to Node.js v15.14.0.
Type ".help" for more information.
> const deepEqual = require('deep-equal');
undefined
> deepEqual({ a: 123, b: NaN }, { a: 123, b: NaN })
false
>

I was expecting deep-equal to return true.

Node's assert.deepEqual says the above objects are equal:

> const assert = require('assert');
undefined
> assert.deepEqual({ a: 123, b: NaN }, { a: 123, b: NaN })
undefined

And this NaN unit test seems to assert that it returns true (?)

Is returning false the expected behavior?

Hi I'm getting some issue with eslint. It has something to do with .eslintrc of this library.

ESLint: 6.2.2.

ESLint couldn't find the config "@ljharb" to extend from. Please check that the name of the config is correct.

The config "@ljharb" was referenced from the config file in "....\packages\...\node_modules\deep-equal\.eslintrc".

Would it be possible to offer an option to compare arrays by members rather than members+order? This is a weaker concept of equality but is sometimes useful when dealing with non-deterministically produced arrays.

I'm pretty sure the change would one or a few lines above the existing array case, but want to at least start the discussion first.

It seems that upgrading to node-deep-equal 2.0.1 results in an error. I'm seeing other posts on this issue within the last few days against other projects, so it's unclear the true origin.

./node_modules/is-map/index.js
SyntaxError .../node_modules/is-map/index.js: 'return' outside of function (12:1)

  10 | 		return false;
  11 | 	};
> 12 | 	return;
     | 	^
  13 | }
  14 |
  15 | var $mapHas = $Map ? Map.prototype.has : null;

DOWNGRADING to deep-equal 1.1.1 resolves the problem in my React (CRA) project.

var equal = require('deep-equal');
equal([0, 1, 2, 3], ['0', '1', '2', '3'])

should return false

Since dates are compared using getTime() method, why regular expressions can not be compared as their string representations?

const foo = /hellowz/i;
const bar = new RegExp('hellowz', 'i');

foo === bar; // false
foo == bar; // false
foo.toString() === bar.toString(); // true

I'd like to, say, deepEqual jQuery('div') === jQuery('div'). This will fail, of course, because they're both the same objects, but they represent the same things.

Is there a way for deepEqual to use a custom comparator function for objects when its available?

yo JSON.stringify() might be a little faster

var timer = process.hrtime()
var deepEqual = require('deep-equal')
console.dir([
    deepEqual(
        { a : [ 2, 3 ], b : [ 4 ] },
        { a : [ 2, 3 ], b : [ 4 ] }
    ),
    deepEqual(
        { x : 5, y : [6] },
        { x : 5, y : 6 }
    )
])
var duration = process.hrtime(timer)
var millis = duration[0] * 1000 + duration[1] / 1000000
console.log(millis)

running this code a few times on my laptop yielded mean average of 14.1853544 ms

each run's actual milliseconds and its node-deep-equal return value went as follows just now:

21:09 $ node bleh.js 
[ true, false ]
13.781762
✔ ~/p/blah 
21:09 $ node bleh.js 
[ true, false ]
13.541187
✔ ~/p/blah 
21:11 $ node bleh.js 
[ true, false ]
14.96483
✔ ~/p/blah 
21:11 $ node bleh.js 
[ true, false ]
14.484085
✔ ~/p/blah 
21:11 $ node bleh.js 
[ true, false ]
14.154908

ok. so about 14 milliseconds. now let's check out some comparative benchmark code:

var timer = process.hrtime()
console.dir([
  JSON.stringify(
    { a : [ 2, 3 ], b : [ 4 ] }
  ) ==  JSON.stringify(
    { a : [ 2, 3 ], b : [ 4 ] }
  ),
  JSON.stringify(
    { x : 5, y : [6] }
  ) ==  JSON.stringify(
    { x : 5, y : 6 }
  )
])
var duration = process.hrtime(timer)
var millis = duration[0] * 1000 + duration[1] / 1000000
console.log(millis)

same return value but mean average drops down to 10.632969 ms

21:21 $ node blah.js
[ true, false ]
10.392282
✔ ~/p/blah 
21:21 $ node blah.js
[ true, false ]
10.412387
✔ ~/p/blah 
21:21 $ node blah.js
[ true, false ]
10.682338
✔ ~/p/blah 
21:21 $ node blah.js
[ true, false ]
11.323075
✔ ~/p/blah 
21:21 $ node blah.js
[ true, false ]
10.354763

benchmark code's stylistic writing of JSON.stringify() takes 100% inspiration from the readme.

i wouldn't normally think to write JSON.stringify() with that type of style but it kinda makes sense here

this could be an isolated case where node-deep-equal's slower performance is largely a result of the module import with file system lookup algorithm running before even second-pass function loading time is taken into account. nonetheless, this shows us that when lighting up a small node process for small object deep equal testing, just using string equality operator == between calls to JSON.stringify() will generally outperform the deep-equal stuff

I've observed very nasty performance regression between v1.0.1 and v1.1.0, causing on average x2 CPU usage in one application, and with localised impact even greater in various situations.

I'll post some benchmarks when I get the chance, but posting this in the meantime to give an early heads up.

This library appears to be quite bloated, according to https://bundlephobia.com/package/[email protected]

I wonder if deep equality checking could be done without so many dependencies.

Hi,
I am having this issue using the grid from the React wrapper.
I have installed the deep-equal dependency but without success.

Here the details of the error:

main.js:193120 Uncaught TypeError: deepEqual is not a function
at reconcileConfiguration (main.js:193120)
at Grid.componentWillReceiveProps (main.js:193053)
at main.js:288153
at measureLifeCyclePerf (main.js:287618)
at ReactCompositeComponentWrapper.updateComponent (main.js:288152)
at ReactCompositeComponentWrapper.receiveComponent (main.js:288089)
at Object.receiveComponent (main.js:46769)
at ReactCompositeComponentWrapper._updateRenderedComponent (main.js:288296)
at ReactCompositeComponentWrapper._performComponentUpdate (main.js:288266)
at ReactCompositeComponentWrapper.updateComponent (main.js:288187)

Any clues?

Thanks!

Laura.

equal([1,2,3], [1,2,3]) -> true

equal([1,2,3], [3,2,1]) -> false

How to get the true from the second statement?

Currently the travis.yml, test and example files/directories are being included in the npm distribution. This is causing a bloated npm distribution.

Given an object, and another to compare against, deepEqual does not compare symbols against either object (nor does it throw an error to indicate such is not supported by the module).

For example:
deepEqual({ [symbol]: bob }, { [symbol]: null }) // returns true.

Which in my case caused tests to appear to pass. I've looked downstream, but I feel this is the most relevant repository as this module depends on the object-keys shim and it is not the fault of the shim.

Because https://github.com/substack/node-deep-equal/blob/master/index.js#L16-L17 tests for typeof !== 'object', this fails to account for the fact that null == undefined (since typeof null === 'object'), resulting in a surprising situation.

See: tapjs/tapjs#155

Would you be open to a PR that addressed this?

Looks like the files property (https://docs.npmjs.com/files/package.json#files) is not used in package.json to specify the included files, nor is the .npmignore file (https://docs.npmjs.com/misc/developers#keeping-files-out-of-your-package) is being used for blacklisting unwanted files, for the package published to npm.

Would you consider adding either the files property or the .npmignore file, so that the resulting package file would have smaller size?

The current size can be seen when executing the command npm pack (https://docs.npmjs.com/cli/pack).

This issue was create via tawata

Example: https://runkit.com/591a7863d76ac2001216d505/591a7863d76ac2001216d506

var deepEqual = require("deep-equal") // v1.0.1

console.log(undefined === null); // false (expected)
console.log(deepEqual(undefined, null)); // true (unexpected)

On Node 6.9:

const deepEqual = require("deep-equal"); // v1.0.1
deepEqual(new Set(['a', 'b', 'c']), new Set(['a', 'b', 'c'])); // true
deepEqual(new Set(['a', 'b', 'X']), new Set(['a', 'b', 'c'])); // true

Two sets should not be equal unless their constituents are the same. (Probably the same issue with Map instances too.)

Hello,

If I compare two ArrayBuffer variables, the result is always true. Here is a PoC:

import { default as assert } from "assert";
import deepEqual from "deep-equal";

const buffer1 = new ArrayBuffer(8); // initial value of 0's
const buffer2 = new ArrayBuffer(8); // initial value of 0's

const view1 = new Int8Array(buffer1);
const view2 = new Int8Array(buffer2);

view1.fill(9); // change all values to 9's
//view2.fill(9);

//console.dir(buffer1);
//console.dir(buffer2);

console.log(
  deepEqual(buffer1, buffer2)
);

assert.deepEqual(buffer1, buffer2);
//assert.deepStrictEqual(buffer1, buffer2);

deepEqual() returns true while Node.js built-in assert.deepEqual() fails correctly with the following:

AssertionError [ERR_ASSERTION]: Expected values to be loosely deep-equal:

ArrayBuffer {
  [Uint8Contents]: <09 09 09 09 09 09 09 09>,
  byteLength: 8
}

should loosely deep-equal

ArrayBuffer {
  [Uint8Contents]: <00 00 00 00 00 00 00 00>,
  byteLength: 8
}
    at // ...cut... //
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: ArrayBuffer {
    [Uint8Contents]: <09 09 09 09 09 09 09 09>,
    byteLength: 8
  },
  expected: ArrayBuffer {
    [Uint8Contents]: <00 00 00 00 00 00 00 00>,
    byteLength: 8
  },
  operator: 'deepEqual'
}

One options to fix this would be to test if the value is of type ArrayBuffer, then create a temporary view of it and compare this view. This works correctly with deepEqual(). However, there may be a more generic fix which I'm unaware of.

The following does not yield the expected result. The order of the entries should not matter but even when ordered, the result is false.

const de = require('deep-equal')

let a = new Map([[{}, 1], [{}, 2], [{}, 1]])
let b = new Map([[{}, 1], [{}, 2], [{}, 1]])

console.log(de(a, b))
// false

a = new Set([{}, 1, {}, {}, 2])
b = new Set([{}, 1, {}, 2, {}])

console.log(de(a, b))
// false

I assumed from reading the code that the following test case should pass:

test('differing types', function (t) {
    t.notOk(equal(["a","b"], {0: "a", 1: "b"}));
    t.end();
});

It doesn't (i.e it considers those objects equal), since prototype is generally undefined unless you're comparing constructor functions. I think you mean:

    if (Object.getPrototypeOf(actual) !== Object.getPrototypeOf(expected)) return false;

(or some equivalent where that function is not available)

Provide an option to check if objects have a deep subset/superset relationship, checking equality at each level of the object hierarchy only on the values of those keys that are shared, or only the keys in first object in the subset case, or only the keys in the second object in the superset case.

@substack wrote in tape-testing/tape#342:

Once this is merged into core I will release a new major version of deep-equal based on the new algorithm that tape can be updated to support.

As far as I can see, node 8 has a deepEqual that can properly compare Maps and Sets:

node-v8.9.4-linux-x64 $ ./bin/node
> const assert = require('assert')
undefined
> assert.deepEqual(new Set('a'), new Set('a'))
undefined
> assert.deepEqual(new Set('a'), new Set('b'))
AssertionError [ERR_ASSERTION]: Set { 'a' } deepEqual Set { 'b' }
>

I find Sets and Maps very useful and want to use them with t.deepEqual() in tape.

I am fixing a bug where arrays have been accidentally converted to objects:

['test', 'the', 'things'] -> { 0: 'test', 1: 'the', 2: 'things' }

I have written a function that tests if this has happened and converts back to the array form. I want to test that my patch works recursively, so it would be very convenient to use deep-equal.

Unfortunately though:

deepEqual(['test', 'the', 'things'], {
    0: 'test',
    1: 'the', 
    2: 'things'
});
// -> true

Would you accept a patch (perhaps with opts) to allow this to return false?

Related to #78, deep-equal v2.0.1 is now causing a 'return' outside of function (12:1) compiler error from is-weakmap, subsequent fixes to is-map and is-set.

STEPS

yarn create react-app my-app --template typescript
cd my-app
yarn add deep-equal
vi src/index.tsx

# Add lines to index.tsx before render()
    import deepEqual from "deep-equal"; // NEW LINE
    deepEqual({}, {});                  // NEW LINE

yarn build

COMPILER ERROR:

Failed to compile.

./node_modules/is-weakmap/index.js
SyntaxError: .../my-app/node_modules/is-weakmap/index.js: 'return' outside of function (12:1)

  10 | 		return false;
  11 | 	};
> 12 | 	return;
     | 	^
  13 | }
  14 |
  15 | var $mapHas = $WeakMap ? $WeakMap.prototype.has : null;


error Command failed with exit code 1.

I've checked with Node.js 0.12.0, and their assert.deepEqual() is able to compare objects with circular references, without running on forever or hitting stack limits.

var assert = require('assert');
var a = {}, b = {};
a.b = b; b.a = a;
assert.deepEqual(a, b);
// throws assertion

Node.js 0.10.36 throws:

TypeError: Converting circular structure to JSON

This isn't as good as actually performing some comparison, but at least it doesn't loop infinitely or anything.

The same thing in tape v3.5.0 with deep-equal v0.2.2 throws:

RangeError: Maximum call stack size exceeded

This might be more of a tape problem, but it actually throws instead of being caught as a failed assertion.

Would it be possible to at least have this return false in this sort of case?

Cheers. Love your work. :)

Sometimes during debug it is hard to determine which exact property/entry/other in nested objects caused inequality.
Serializing both and comparing manually is not easy as items may be in different order.
Maybe you could provide some execution flag or separate method that instead of bool returns path to discrepancy?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• [Deps] Update Update eslint to v8.57.0
• [Deps] Update Update eslint to v9
• [Deps] Update Update nyc to v17
• [Deps] Update Update semver to v7
• [Deps] Update Update actions/checkout action to v4
• [Deps] Update Update codecov/codecov-action action to v4
• 🔐 Create all pending approval PRs at once 🔐

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Consider the following tests.

These tests have been added to my fork and you can see them here: https://github.com/Xotic750/node-deep-equal

test('arrays initiated', function (t) {
    var a0 = [
            undefined,
            null,
            -1,
            0,
            1,
            false,
            true,
            undefined,
            '',
            'abc',
            null,
            undefined
        ],
        a1 = [
            undefined,
            null,
            -1,
            0,
            1,
            false,
            true,
            undefined,
            '',
            'abc',
            null,
            undefined
        ];

    t.ok(equal(a0, a1));
    t.end();
});

test('arrays assigned', function (t) {
    var a0 = [
            undefined,
            null,
            -1,
            0,
            1,
            false,
            true,
            undefined,
            '',
            'abc',
            null,
            undefined
        ],
        a1 = [];

    a1[0] = undefined;
    a1[1] = null;
    a1[2] = -1;
    a1[3] = 0;
    a1[4] = 1;
    a1[5] = false;
    a1[6] = true;
    a1[7] = undefined;
    a1[8] = '';
    a1[9] = 'abc';
    a1[10] = null;
    a1[11] = undefined;
    a1.length = 12;

    t.ok(equal(a0, a1));
    t.end();
});

test('arrays push', function (t) {
    var a0 = [
            undefined,
            null,
            -1,
            0,
            1,
            false,
            true,
            undefined,
            '',
            'abc',
            null,
            undefined
        ],
        a1 = [];

    a1.push(undefined);
    a1.push(null);
    a1.push(-1);
    a1.push(0);
    a1.push(1);
    a1.push(false);
    a1.push(true);
    a1.push(undefined);
    a1.push('');
    a1.push('abc');
    a1.push(null);
    a1.push(undefined);
    a1.length = 12;

    t.ok(equal(a0, a1));
    t.end();
});

The first test passes but the the others fail. Why? Because IE<9 creates an index for the undefined entries when initiated, but in the other creations no index is created even though the array length is modified. The effect of this is that the object keys length test fails. So, to avoid this you need to avoid the use of the objecy keys shim. Underscore isEqual works because it takes the more expensive route of traversing each index. This problem affects all libraries that base their deepEqual routine on nodes assert routine (ie, assert, expect, proclaim, TAPE are to name a few)

Today I found out about this: https://nodejs.org/dist/latest-v17.x/docs/api/util.html#utilisdeepstrictequalval1-val2.

In the README where it says:

This module is around 46 times faster than wrapping assert.deepEqual() in a try/catch.

It should also compare with isDeepStrictEqual and let people know that if they are using Node.js they can use isDeepStrictEqual.

The devDependency eslint was updated from 6.7.1 to 6.7.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

hello/

package content here https://npmfs.com/package/deep-equal/1.0.1/lib/keys.js

I'm a little confused by the history here. maybe git history got screwed up? or some commits were backdated and github does not show them correctly?

file history: https://github.com/inspect-js/node-deep-equal/commits/master/lib/keys.js
commits: https://github.com/inspect-js/node-deep-equal/commits/master

It seems like @ljharb replaced keys.js to use the package on Apr 3, 2013
1.0.1 was commited Aug 30, 2015 (years later) but seems the keys.js replacement is missing when you look at those commits https://github.com/inspect-js/node-deep-equal/commits/59c511f5aeae19e3dd1de054077a789d7302be34

anyways, if you could publish a new version with the keys.js replacement, that would be appreciated. thanks/

Hi,

Although node-deep-equal includes a LICENSE file, there is unfortunately no statement of copyright, which is necessary if it is to be uploaded to Debian.

Kind regards,

Tim

const a = new Error('a')
const b = new Error('b')
const strict = true

require("deep-equal")(a, b, { strict }) // true

https://runkit.com/57e01e376dc2ad1400d39ab3/584826c627aa8e0013a1adcd

This package got new field in package.json

  "exports": {
    ".": [
      {
        "default": "./index.js"
      },
      "./index.js"
    ],
    "./package": "./package.json",
    "./package.json": "./package"
  },

However, it doesn't work.

To reproduce the error, go to an empty folder.

npm i deep-equal
node
> require('deep-equal/package.json')
Uncaught Error: Cannot find module 'deep-equal/package.json'
Require stack:
- <repl>
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:965:15)
    at Function.resolve (internal/modules/cjs/helpers.js:78:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [ '<repl>' ]
}

The fix:
Change

"./package.json": "./package"

To

"./package.json": "./package.json"

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

node: 12.16.1
npm: 6.14.2
eslint: ^6.8.0

when performing npm install I get the following error:
[!] (plugin eslint) Error: Failed to load config "@ljharb" to extend from.
Referenced from: /node_modules/deep-equal/.eslintrc
node_modules/deep-equal/index.js

Please let me know if you need any more details. We are not directly requiring deep-equal, but I'm not sure which package calls it as a dependency.

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

@substack , good day!

Is this package intended/considered to be compatible with NodeJS?

I'd like to prepare patches for NodeJS master branch assert.deepEqual (tests) compatibility if you merge it...

Thanks!

So, sparse arrays are deep equal with underscore:

_.isEqual([,], [undefined]) // true

deepEqual([,], [undefined]) // false

This is because sparse arrays have a different set of reported keys with Object.keys. Any idea which one should be right?

I am not sure why #35 was closed, but it is still an issue. Please do not include test and example in the directories for package.json. They should not be included in the npm distribution.

I know you say it's covered under MIT license, but the license does say:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

... which, if I understand correctly, means that you need to include the text of the license.

Refs: nodejs/node#8169, nodejs/node#7152.

Two options here:

• Use the new Buffer API — Buffer.alloc()/Buffer.from()/Buffer.allocUnsafe() (requires a shim for v0.10/v0.12 and older v4.x versions prior to v4.5.0).
• Use new Buffer() for the time being — just add the new keyword everywhere. You should manually check that everything is safe in this case, see the links below for more explanation. That might be hard-deprecated at some later point.

More background:

• https://github.com/ChALkeR/notes/blob/master/Lets-fix-Buffer-API.md
• https://github.com/ChALkeR/notes/blob/master/Buffer-knows-everything.md
• nodejs/node#7152 (comment)

Quick grep (you should better re-check):

deep-equal-1.0.1.tgz/test/cmp.js:82:    t.ok(equal(Buffer('xyz'), Buffer('xyz')));

The grep above only includes the lines that call Buffer() without the new keyword, if you choose to move to the new API — you should probably also replace new Buffer(…) calls.

Can we add support for ES2015 Map/Set objects? Currently (version 1.0.1):

var a = new Map
a.set(0, 'a')
var b = new Map
b.set(0, 'b')
deepEqual(a, b) // true
deepEqual(new Set('a'), new Set('b')) // true

We also need this for mjackson/expect#47