Nolyfills for @stdlib?

[hfhchan-plb]

I'm seeing huge graphs in stdlib with deps which are absolutely unreal.

Examples:

• @stdlib/assert-is-boolean
  

• @stdlib/assert-is-function
  

[hfhchan-plb]

On further inspection it looks like they have accidentally included @stdlib/cli-ctor and @stdlib/fs-read-file in dependencies instead of devDependencies (tracked at stdlib-js/stdlib#2469), but assert-is-function / assert-s-array are still way overboard with poisonous dep chains.

[SukkaW]

I noticed that assert-is-function behaves differently than typeof, so probably we can't simplify it to typeof x === 'function'.

[kgryte]

assert-is-function / assert-is-array are still way overboard with poisonous dep chains.

@hfhchan-plb We don't need to litigate on this issue, but this is a mischaracterization. stdlib simply splits out requisite functionality into separate well-defined APIs. It does not bring in "poisonous" external dependencies. The reason for modularity is to allow code reuse across multiple packages. This, in turn, allows users who depend on more stdlib functionality to benefit from smaller, not larger, eventual bundle sizes, as utilities and helpers are not duplicated across packages.

If you want standalone modules without dependency chains, that is fine; we provide that. Just use our UMD builds (see https://github.com/stdlib-js/assert-is-function#installation).

[hfhchan-plb]

@kgryte Apologies.

While cleaning up deps in a project I am on, I found many packages from @StdLib, many with names looking suspiciously similar to other packages that nolyfill replaces.

This turns out to be due to @segment/tsub lib, which was included in our project recently, resulting in over 98 packages being imported from @StdLib, with many packages referencing each other. I couldn't even load the dep graph without the page lagging every time I scrolled on my mbp M1.

In my initial investigation, I believe some of these deps to be false positives, hence I opened the other issue stdlib-js/stdlib#2469 instead.

Based on your response I believe the core issue is that @segments/tsub (coming from @segment/analytics-next) is pulling in severely outdated versions of libraries. I can confirm the newest version of @stdlib/math-base-special-ldexp no longer has deps on CLI tools.

Unfortunately it looks like segment has paused development for @segment/tsub, while still using it as a dep, and there is already an open ticket requesting the lib to be updated to 0.2.1 (segmentio/tsub-js#45).

Based on that, I doubt upstream will be able to change to UMD builds in a short amount of time.

[hfhchan-plb]

@SukkaW

There are still a significant amount of indirect deps with the newest version of @stdlib/math-base-special-ldexp. E.g. @stdlib/assert-is-function, @stdlib/assert-is-plain-object, @stdlib/utils-get-prototype-of, @stdlib/math-base-assert-is-infinite etc still have huge chains.

Looking at assert-is-function, which is basically a thin wrapper over utils-type-of, behaviour is changed only to fix wrong behaviour from Chrome 1 - 12, Safari 8, and PhantomJS (see: https://github.com/stdlib-js/utils-type-of/blob/main/lib/check.js). All three of which are long dead, and deader than Node 12. I suppose it should be safe to replace this with `typeof x === 'function'.

[Artoria2e5]

For the case of @stdlib/math-base-assert-is-infinite, I think there is a bogus dependency (should be dev-only... or is it required for gyp installation?) @stdlib/utils-library-manifest. Honestly I find the very idea that a function that does this needs to have a native version surprising, even without taking into account the existence of Number.isFinite().

math-base-special-ldexp is good though. It interprets the float as an integer, as any good libm would do, then manipulates that. That I can respect. (I can't really get over its copysign dependency having to do the same kind of type punning though. Surely there's a better way: either do it without punning, or at least skip a type-pun roundtrip by exposing a version that takes the two converted words directly?)

I don't quite have the energy to manually look through package.json recursively for the rest. Someone probably has a graphviz chart somewhere.

[kgryte]

@Artoria2e5 For context, @stdlib/utils-library-manifest is not a bogus dependency. stdlib focuses heavily on numerical computing applications. As part of that, the project provides APIs both in C and JavaScript. For the former, the project provides a basic C package management system (utils-library-manifest) for dynamically assembling native binaries which stitch together individual APIs into larger libraries and applications. utils-library-manifest works by performing resolution across the node_modules directory tree. One can leverage C assembly for building a Node.js native add-on or a WebAssembly module, which is already done in service of higher level APIs in the project.

This stated, we are investigating a way to reduce dependency depth on base mathematical functions. But if you have concerns, questions, or opinions, I suggest you reach on stdlib's official dev channels.