Please consider to remove the dependency on typedarray.prototype.slice package

[Skywalker13]

Hello,

First, thank you for this module that I use since a lot of years. But this module installs typedarray.prototype.slice as dependency. And this shim is obsolete (because current engines support it) since a lot of years too. The main "problem" is that this dependency installs a lot of other dependencies. The dependency graph is huge just for something "useless" today.

Then please, remove this dependency.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/slice

Regards

[ljharb]

It's not just about being a polyfill (this package supports all node versions, including some without the function), it's about robustness. Removing it would be a breaking change, and would make the package less robust on modern engines too.

[lpil]

What does robustness mean for modern engines? Thank you.

[foxt]

Removing it would be a breaking change

The dependency was added in https://github.com/ljharb/js-traverse/commit/18c32c5ba8ebc84344925198bb29b6def97471fd, which was in August 2023, 8 years after Node 4.0.0 (the first version to include typedarray.slice according to MDN). In fact, before that commit, traverse has had no dependencies.

I seriously doubt that there are a substantial amount or, even any users that in the past year are still developing for Node 3.x, and installed this page, that cannot upgrade to a more modern runtime, or just pin their dependency on traverse to a previous version.

[ljharb]

@foxt semantic versioning has zero consideration for "how many people might be using it", but it's also unknowable. and, again, it's not about whether TA slice is present, but it's about making it robust even if someone has deleted it off the globals.

[lpil]

So the idea is the dep is so your code works even if someone mutates global objects?

[ljharb]

@lpil yes, that's intended to be the case for all my packages (as long as the mutation is done after the module is loaded ofc; it's not possible in JavaScript to defend against prior-run code, only later-run code)

[SamLebarbare]

Proposal: Make a major with backward compatibility support as an optional peer dependency in the package.json ?

"peerDependencies": { 
   "typedarray.prototype.slice": "^1.0.3"
},
"peerDependenciesMeta": {
  "typedarray.prototype.slice": {
    "optional": true
  }
}

[lpil]

What a great idea! Love it!