chaijs/loupe

Inspect utility for Node.js and browsers

loupe's Issues

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

inspect of Object with null prototype causes primitive value error

It seems that when the check of the object type to know how to inspect, if the object has been created from a null prototype, it doesn't match any of the existing checks during the inspect, and then falls to just treat it as a string - which complains with Cannot convert object to primitive value.

This has started causing errors with our pipeline using chai - as chai previously matched these objects, but since a chair release that moved to Loupe a couple of weeks ago, this has started failing builds due to complex objects crashing the inspect.

broken dependency `get-function-name`

In continuation of #40

Also, dependency https://github.com/sorensen/get-function-name.js is broken; it apparently results in these lines in the build:

	var getFunctionName = function(fn) {
	  if (toString$1.call(fn) !== '[object Function]') return null
	  if (fn.name) return fn.name
	  var name = /^\s*function\s*([^\(]*)/im.exec(fn.toString())[1];
	  return name || 'anonymous'
	};

This code does not deal with anonymous arrow function and does not even honor the fact that the RegExp::exec() method may return null on mismatch. Apart from that, the code above is fairly convoluted for what it does.

add an option to render functions as their body

for example:

const inspectFunction = fn => fn.toString()

inspectFunction(() => 3) 
// () => 3

inspectFunction(function(a, b, c) { return a + b + c })
// "function(a, b, c) { return a + b + c }" 

Handle circular references

The following code raises an error:

const loupe = require('loupe');
const a = {};
a['b'] = a;
loupe.inspect(a)

I would expect it to display:

{ b: [Circular] }

but for now it raises:

Uncaught RangeError: Maximum call stack size exceeded
    at _arrayWithHoles (./chai/node_modules/loupe/loupe.js:406:26)
    at _slicedToArray (./chai/node_modules/loupe/loupe.js:403:11)
    at inspectProperty (./chai/node_modules/loupe/loupe.js:625:16)
    at inspectList (./chai/node_modules/loupe/loupe.js:587:27)
    at inspectObject (./chai/node_modules/loupe/loupe.js:920:27)
    at Object.inspect (./chai/node_modules/loupe/loupe.js:1150:13)
    at inspectProperty (./chai/node_modules/loupe/loupe.js:636:20)
    at inspectList (./chai/node_modules/loupe/loupe.js:587:27)
    at inspectObject (./chai/node_modules/loupe/loupe.js:920:27)
    at Object.inspect (./chai/node_modules/loupe/loupe.js:1150:13)

Is the custom `inspect()` still needed?

I have an issue raised upstream with vitest which had me do some digging here, I am wondering if the custom inspect() function is still required? All the build configuration files I can see here suggest that this package is targeting esm and esnext which will have symbol support. That and the recent https://github.com/chaijs/loupe/releases/tag/v3.0.0 release seem to back this up.

Specifically, I am asking if the named inspect() function is still required when we have the two symbol https://github.com/chaijs/loupe/blob/main/src/index.ts#L99C7-L99C18 variants available to us.

`depth` option

I wasn't able to find any documentation about the options. From the description, I would assume it works somewhat similar to Node.js inspect:

It's similar to Node.js' util.inspect() function, but it works cross platform, in most modern browsers as well as Node.

But it looks like this package doesn't support depth option correctly. From my experience:

const nestedObj = { n: { a: { b: { c: { d: { e: '3' } } } } } }

loupe(nestedObj)
// prints this:
// { n: { a: { b: { c: { d: { e: '3' } } } } } }


util.inspect(nestedObj)
// prints this:
 // { n: { a: { b: [Object] } } }

Is this intentional? If I pass down depth: 2 manually, I still get the full object printed.

Offer to help

Hi, prompted by chaijs/chai#662 (comment) I took a look at this repo, but there hasn't been any activity for a while. I guess it's on someones computer, but I thought I should offer to help.

IE9+ not supported since 4.3.5 because of loupe

The official website says Chai supports IE version 9 and above, however out tests started to fail in IE after upgrading Chai to version 4.3.5 or 4.3.6. Tests in IE throw a "Syntax Error" inside loupe. Would it be possible to remove this dependency or shall I rather open an issue against loupe to fix IE support?

Workaround: Downgrade Chai to 4.3.4.

Handle circular references better

It looks like #44 isn't fully fixed.

It's hard to make a repro because I'm using loupe via Vitest, but it seems to be a problem with https://github.com/WebReflection/linkedom and some documents:

The repro should look something like:

import {parseHTML} from 'linkedom';

const request = await fetch('https://github.com/refined-github/refined-github/issues', {
	headers: {
		Accept: 'text/html',
	},
});
const html = await request.text();
const {document} = parseHTML(html);
const matches = document.querySelectorAll('a');

assert.lengthOf(matches, 100)

The assertion probably gets caught up trying to preview the DOM objects, which has plenty of circular references. I'm not sure what's wrong with the DOM generated by that particular page, but it fails there and not on other similar pages.

RangeError: Maximum call stack size exceeded
 ❯ inspectProperty node_modules/loupe/loupe.js:254:27
 ❯ inspectList node_modules/loupe/loupe.js:208:28
 ❯ inspectObject node_modules/loupe/loupe.js:575:28
 ❯ inspectClass node_modules/loupe/loupe.js:606:35
 ❯ Object.inspect node_modules/loupe/loupe.js:850:16
 ❯ inspectProperty node_modules/loupe/loupe.js:268:21
 ❯ inspectList node_modules/loupe/loupe.js:208:28
 ❯ inspectObject node_modules/loupe/loupe.js:578:26
 ❯ Object.inspect node_modules/loupe/loupe.js:838:14
 ❯ inspectProperty node_modules/loupe/loupe.js:268:21

Loupe doesn't work correctly for buffers

Example:

inspect(Buffer.from([2,3,4]))

returns

'Buffer[ 2, 34,  ]'

I think the problem is on the line:

loupe/lib/typedarray.js

Line 27 in 32b7276

array[i] === array.length ? '' : ', '

vulnerability in loupe

i found vulnerability in loupe module. where can I report this?

TODO for v2 Release

Here's a short list of things we'll probably need to do to get this ready for publishing:

Bare Minimum

• get npm t passing locally (fails on safari for me)
• Get CI passing (fails on lint check it seems now fails on saucelabs)
• Totally rewrite the readme so it makes more sense.

Probably should do:

• Update all deps/devdeps so we're in a good clean state

Would be really nice to have

• Migrate to github actions and drop travis ci
• Separate lint check in GH Actions
• Separate node/browser tests in GH actions

Stretch goals

• Migrate commitlint to github actions
• Migrate codecov to github actions checks

Package `loupe` seems to be an ES Module but shipped in a CommonJS package

I upgraded to vitest 0.30.1 and started getting this error. It says to file an issue against the repo, is this correct?

Module E:/ComfyBox/node_modules/.pnpm/[email protected]/node_modules/loupe/index.js:7 seems to be an ES Module but shipped in a CommonJS package. You might want to create an issue to the package "loupe" asking them to ship the file in .mjs extension or add "type": "module" in their package.json.

As a temporary workaround you can try to inline the package by updating your config:

// vitest.config.js
export default {
  test: {
    deps: {
      inline: [
        "loupe"
      ]
    }
  }
}

`inspect( 1n )` => no joy

Title says it all.

I tried to fix it and jeez you guys should clean up your code.

There's a serious systematic fault here at play in that execution for unknown types will hit if ( 'constructor' in value ) around line 1161 which causes an exception e.g. with bigints. Fix is of course to add that one to the list of known types, but this won't prevent an exception for any new types that get added to JS. For what it does (and it worked well for me so far) the code is much too convoluted IMHO. Also unnecessarily 'abstracty' where abstraction doesn't buy you anything. Case in point, you return fancy formatting handlers for undefined, null, true, false, when the representations for these values are just these very strings and you're done. All types have aliases with lower and upper case. Type checking is wrapped inside a CSJS polyfill. There is a section dedicated to HTMLTableHeaderCellElement. Wat, seriously. Some code meant to be used by Chai objects only is thrown in, in no meaningful way separated from the general-purpose stuff (this almost made me toss loupe altogether).

Here I donate you some code:

domenic_denicola_device  = ( x ) -> x?.constructor?.name ? './.'
mark_miller_device       = ( x ) -> ( Object::toString.call x ).slice 8, -1
# mark_miller_device       = ( x ) -> ( ( Object::toString.call x ).slice 8, -1 ).toLowerCase().replace /\s+/g, ''
js_type_of   = ( x ) -> ( ( Object::toString.call x ).slice 8, -1 ).toLowerCase().replace /\s+/g, ''

IMO these are good starts to radically simplify the type checking stuff. Have fun.

Return value for number 0

I wanted to know why we return +0 or -0? In chai we just use 0.

loupe/lib/number.js

Line 15 in 0c75417

return options.stylize(1 / number === Infinity ? '+0' : '-0', 'number')

3) expect
    empty:

      AssertionError: expected '.empty was passed non-string primitive +0' to equal '.empty was passed non-string primitive 0'
      + expected - actual

      -.empty was passed non-string primitive +0
      +.empty was passed non-string primitive 0
      
      at globalErr (test/bootstrap/index.js:52:57)
      at Context.<anonymous> (test/expect.js:1597:5)
      at processImmediate (internal/timers.js:461:21)

Quote complex keys in objects

Currently inspection of an object with a complex key (e.g. with a dot) returns something that is not syntactically valid.

See chaijs/chai#1401 (comment)

loupe.inspect({'a.b': 1})

returns { a.b: 1 } but we would prefer { 'a.b': 1}

Pass in a secondary object to display better info about the inspected value

Following from chaijs/chai#469 - we should be able to use loupe() to have a shallow inspection on different properties of a value (but without becoming a full diffing engine). To quote my own words in chaijs/chai#469:

There is another part of the puzzle though, and that's chai's inspection engine. The message which says 'AssertionError: expected [ Array(2) ] to deeply equal [ Array(2) ]' is from Chai, and we use our own inspection library (found here) to create these.

I think here we have a lot of room to make things better. [ Array(2) ] isn't that useful, [ [1, 2] ] would be more useful I'm guessing - but we need to strike a good balance between too much info and too little.

Can I suggest we move the topic of conversation on how to deal with these small arrays and objects within messages? Here's the code for formatting Arrays - we could place in some length checks and try to output the full contents of short Arrays, or truncate them in the middle and only show [0..2, n-2..n].

I think we could go further, because we have knowledge about the actual and expected properties - that we could supply to loupe to generate more interesting inspection strings from within loupe, for example:

// Inspecting a standard value.
loupe({ foo: 1, bar: 1, baz: 1 }) === '{ foo: 1, bar: 1, baz: 1 }';
// Inspecting a value with a comparison value, to generate a better representation of the first object:
var actual = { foo: 1 };
loupe({ foo: 1, bar: 1, baz: 1}, { diff: actual }) === '{ ... bar: 1, baz: 1 }';

The example above isn't the most clear - because the benefit isn't really properly demonstrated on such small objects, but imagine objects or TypedArrays or Buffers which have hundreds of values and we just show a very poor representation without giving useful info about them:

loupe(my1MbPngFile) === '<Buffer 28 66 75 6e 63 74 69 6f 6e 28 66 29 7b 69 66 28 74 79 70 65 6f 66 20 65 78 70 6f 72 74 73 3d 3d 3d 22 6f 62 6a 65 63 74 22 26 26 74 79 70 65 6f 66 20 ... >'

loupe(my1MbPngFile, { diff: mySubtlyDifferent1MbPngFile }) === '<Buffer ... 75 ... 6a 7c ...>'

cha.expect(my1MbPngFile).to.deep.equal(mySubtlyDifferent1MbPngFile);
// ^ throws `expected '<Buffer ... 75 ... 6a 7c ...>' to equal '<Buffer ... 76 ... 44 7f ...>'`

Invalid Date object will throw a TypeError

The example below will throw a TypeError on line 5 in date.js, because there is no guard against dateObject.toJSON() returning null. Which is the case for invalid dates.

Reproduction

const { inspect } = require ('loupe')

inspect (new Date ('not a date')) // <- TypeError: Cannot read properties of null (reading 'split')

Ref: vitest-dev/vitest#2216

prevent `playwright` installation

Current behavior

The postinstall script installs playwright using npx.

When installing loupe during a GitHub Actions workflow, this seems to intermittently cause installation errors. I've re-run several workflows, several times, to workaround this.

Expected behavior

Playwright should be not be installed unless defined in my package dependencies.

Possible solutions

• add playwright to devDependencies
• refactor postinstall script

Environment

  Binaries:
    Node: 20.8.0 - ~/.nvm/versions/node/v20.8.0/bin/node
    Yarn: 4.0.0 - ~/.yarn/bin/yarn
    npm: 10.1.0 - ~/.nvm/versions/node/v20.8.0/bin/npm
  npmPackages:
    chai: 5.0.0-alpha.2 => 5.0.0-alpha.2
    loupe: 3.0.0 => 3.0.0 

Time representation difference in Chai.js

Is it better to change the time representation in loupe or chai.js tests?

  21) should
       most(n) (dates):

      expected 'blah
      + expected - actual

      -blah: expected 2021-01-27T09:34:22.030Z to be at most 2021-01-27T09:34:21.030Z
      +blah: expected Wed, 27 Jan 2021 09:34:22 GMT to be at most Wed, 27 Jan 2021 09:34:21 GMT
      
      at globalErr (test/bootstrap/index.js:52:57)
      at Context.<anonymous> (test/should.js:1128:5)
      at processImmediate (internal/timers.js:461:21)

New release for Dependabot Fix?

Hey, just wondering when is the next scheduled release so that folks can bump #66 via package.json?