util: canonicalize namespaced tags in inspect()

[Renegade334]

Precursor to adding support for Temporal objects in #63154.

Namespaced toString tags are becoming more common in ES builtins. inspect() currently has no logic for dealing with these, leading to rather ugly output:

> new WebAssembly.Memory({ initial: 1 })
Memory [WebAssembly.Memory] {}

This PR adds logic to handle namespaced tags. If the basename of the namespaced tag matches the constructor name, then it will be treated as the canonical name for that object.

> new WebAssembly.Memory({ initial: 1 })
WebAssembly.Memory {}

Derived classes retain the same behaviour as exists currently.

> class MyMemory extends WebAssembly.Memory {}
> new MyMemory({ initial: 1 })
MyMemory [WebAssembly.Memory] {}

Note that this replaces, and effectively reverts, some previous logic that existed here from #59687. That PR made partial string tag matches suppress the derived class output, so derived class instances might be formatted as either derived classes or base classes depending on how they're named:

> class Base { [Symbol.toStringTag] = 'Base' }
> class LooksLikeADerivedClass extends Base {}
> new LooksLikeADerivedClass()
LooksLikeADerivedClass [Base] {}
> class LooksLikeABaseClass extends Base {}
> new LooksLikeABaseClass()
LooksLikeABaseClass {}

This logic doesn't really fit with namespaced tags and was fairly quirky to start with, and I think the easiest approach is just to replace it entirely. (cc @BridgeAR, @miguelmarcondesf)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.11%. Comparing base (54b4e37) to head (ad239e3).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #63257      +/-   ##
==========================================
- Coverage   90.13%   90.11%   -0.03%     
==========================================
  Files         751      751              
  Lines      253635   253630       -5     
  Branches    47786    47796      +10     
==========================================
- Hits       228615   228555      -60     
- Misses      16268    16315      +47     
- Partials     8752     8760       +8     

Files with missing lines	Coverage Δ
lib/internal/util/inspect.js	97.06% <100.00%> (-0.01%)	⬇️

... and 34 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[legendecas]

I think it is not straightforward to write a class with . in its name, like class Namespace.Class {} is not valid. So we can branch here with the presence of . and keep the original behavior, right?

[Renegade334]

As in the previous suppression behaviour?

I really do think that divergent behaviour isn't helpful here – there's no difference between the inheritance models of class MapDerived extends Map and class InstantDerived extends Temporal.Instant, so I can't see that formatting one as a primary class and one as a derived class is at all useful for users.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[Renegade334]

@BridgeAR Do you have an opinion on this?

As mentioned, this is mainly observable in the context of Temporal objects. Formatting these as

ZonedDateTime [Temporal.ZonedDateTime] {...}

is overly verbose, and implies that these are derived subclasses when they're not.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76457/