In the regular jest .toEqual(), you see the line in the JSON that is off with all the surrounding JSON lines. In this package's .toBeDeepCloseTo() you only see the line in the JSON that doesn't match - with no context of where in the JSON it appears - not even the key.

Installing the package via npm i jest-matcher-deep-close-to lacks the ts definitions.

This is the case while the last commit (2cf2890) to the master introduces ts definitions.

To avoid having to add this boilerplate to each test file that uses the library:

import {toBeDeepCloseTo,toMatchCloseTo} from 'jest-matcher-deep-close-to';
expect.extend({toBeDeepCloseTo, toMatchCloseTo});

the expect.extend line could instead be added at the bottom of index.js in which case the expectations can be made globally available in a user's jest.config.js with something like:

module.exports = {
    setupFilesAfterEnv: [
        'jest-extended',  // https://github.com/jest-community/jest-extended
        'jest-matcher-deep-close-to',  // https://github.com/maasencioh/jest-matcher-deep-close-to
        './jest-extensions',  // Our own extensions
    ],
}

I'd make a PR for this but I'm not set up for hacking on typescript code and this itch isn't annoying enough.

looks like the code is hard built around arrays and objects. If you use the iterator pattern (and types) described here: https://www.typescriptlang.org/docs/handbook/iterators-and-generators.html

the library could support Sets, Maps or any other object that has implemented the interface. Would you be open to a PR on that?

This passes:

expect(0.25005635416666666).toBeCloseTo(0.25);

This fails:

expect([0.25005635416666666]).toBeDeepCloseTo([0.25]);

I would expect the two cases to work the same.

It would be nice if there were a changelog in the releases section to see what gets updated with each major/minor version

Ambient types from jest.d.ts are not visible by default when installing. For now the workaround is to copy this file locally to the source folder, but it would be nice if it was injected into output.

When I install this package via yarn or npm it doesn't contain any type definition file.
Would be nice to add it.

Something like this (based on your index.d.ts file):

declare module "jest-matcher-deep-close-to" {
    export function toBeDeepCloseTo(
        received: number | number[] | object,
        expected: number | number[] | object,
        decimals?: number
    ): {
        message(): string;
        pass: boolean;
    };
    export function toMatchCloseTo(
        received: number | number[] | object,
        expected: number | number[] | object,
        decimals?: number
    ): {
        message(): string;
        pass: boolean;
    };

    declare global {
        namespace jest {
            interface Matchers<R> {
                toBeDeepCloseTo: (expected: number | number[] | object, decimals?: number) => R;
                toMatchCloseTo: (expected: number | number[] | object, decimals?: number) => R;
            }
        }
    }
}

Split in validators for each kind, like was proposed in stalled PR #6

I get the following:

expect(new Float32Array([1, 1])).toBeDeepCloseTo([1, 1], 6);
// error:
    The current data type is not supported or they do not match:
      "object"
    Received:
      "object"

I'm testing a lot of numbers that are the result of looped calculations and the further the go the more 'off' they will be, but still potentially acceptably.

I was thinking to test these a within percentage of sort of function would be great and since they're in objects I was happy to find your library. Wondered if you had any interest in extending it in that area..

I'm not sure of an equivalent name of a test to build off of though

Why not merge this entire repo into the standard jest library?

The test currently fails if a function type is encountered in the nested object. This can become troublesome when we're comparing objects that contain class instances with those instances containing function definitions as well.

Can we add logic to compare functions using strict equality? I could create a PR for this if needed.