inline isArray

[calvinmetcalf]

alternative to #234 if we don't want to deal with potential breaking changes

[kgryte]

Inlining is a perfectly acceptable solution and entails negligible maintenance cost.

[jdalton]

I dig the spirit but it's copying the package verbatim 🤒
Might as well just stick with the package until you can bump and remove it. \cc @juliangruber

[calvinmetcalf]

from my understanding the main issue is not the size but the extra downloads, we talked at the wg meeting of doing some similar things for some of our other deps like process-nextick-args and buffer-shims

[jdalton]

The issue wasn't removing a dependency for the sake of it being another dependency. It was that the ecosystem is at a place where shims for Array.isArray are no longer necessary and that it could be dropped. That's why waiting until a major bump to drop was fine.

[calvinmetcalf]

I don't think we're against removing it per-say just that it would be a major version bump to remove it completely and it wouldn't make sense to be one on its own, at the same time others have expressed issues with there being too many dependencies making npm installs take a lot of time and the 3 line isArray module seemed like low hanging fruit

[jdalton]

I don't think we're against removing it per-say just that it would be a major version bump to remove it completely and it wouldn't make sense to be one on its own,

It wouldn't have to be on its own. It could have waited for whenever the major bump came is all.

at the same time others have expressed issues with there being too many dependencies making npm installs take a lot of time and the 3 line isArray module seemed like low hanging fruit

I can see the pressure from that side, though with yarn install times are much better 😀

[mathiasbynens]

This change violates isarray’s MIT license. “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.”

---

Licensing issues aside, #234 really seems like a much better solution in general (even if it can only happen at the next major version bump).

[calvinmetcalf]

yeah I should probably pull in a copy of the isarray license unless @juliangruber chimes in that simply referencing the license instead of including it (but including the copyright notice) is fine

[timoxley]

Isn't this what bundledDependencies is for?

[mcollina]

Yes, I think we can use bundleDependencies. Can we revert this and use bundleDependencies instead?
Like NPM does: https://github.com/npm/npm/blob/latest/package.json#L108.

[calvinmetcalf]

yeah we could do that for isArray, process-nextick-args,buffer-shims,core-util-is, and util-deprecate. inherits and string_decoder are depended upon by other things so it's highly likely they would be able to take advantage of deduping.

That doesn't actually address @jdalton's main point which was that we don't actually need Array.isArray and we should remove it in the next major version which I think is pretty sensible.

[mcollina]

@calvinmetcalf I absolutely agree that we should drop support for older versions of Node & Browsers whenever we bump the major.

[kangax]

OT: How does the license even make sense here? I mean... it's nice that someone put it into a convenient npm package and I realize that npm packages require license but licensing toString.call()=='[object Array]' is akin to licensing [].slice.call(args). It should just be removed when including it here.

[jmshal]

I'm with @kangax here. I feel like it's rather different than the scenario you've mentioned, @jdalton.

All the package is is a single line function. It's the same function I've written many times in the past, but I would never consider it owned by somebody else purely because somebody else has written the same thing and just so happened to have slapped an MIT license to it.

[kangax]

I don't think licensing applies to labor work but instead to an intellectual property, which this isn't. No offense to @juliangruber, who I'm sure put in the work, but it's simply wrong to attach an MIT license (that carries restrictions) to a one-line pattern that was discovered way back and has been used extensively ever since. Both Mark Miller and I wrote about it as far back as in 2009 (without claiming any kind of copyright; it's just a language that we all use and learn/discover/share!) — http://perfectionkills.com/instanceof-considered-harmful-or-how-to-write-a-robust-isarray/

[jdalton]

As others have mentioned they can leverage bundle deps and drop in major version bump so folks don't have to bikeshed whether it's OK to steal someone else's work. Geez y'all. It's all good 😎

[juliangruber]

No offense to @juliangruber, who I'm sure put in the work, but it's simply wrong to attach an MIT license (that carries restrictions) to a one-line pattern that was discovered way back and has been used extensively ever since. Both Mark Miller and I wrote about it as far back as in 2009 (without claiming any kind of copyright; it's just a language that we all use and learn/discover/share!)

This is not a matter of interpretation or judging whether you think the licensing seems fit for the amount of code. This library is licensed as MIT and thus needs to have the license attached, wherever it's used. You're free not to use it, to hate it, rewrite it, whatever. But that's how it is.

I'm for using bundled dependencies too for that matter, if this really is a problem that needs to be solved.

I would also gladly accept 1 Mio USD to lift the licensing restrictions attached to said piece of software. Up to you!

EDIT: Also keep in mind that a one line module always is more than one line of code. It's documentation, tests, and history in the repo. ..Summoning @sindresorhus :)

[calvinmetcalf]

hey @juliangruber thanks for publishing isArray as a module, I think we're going to go with the bundledDependencies option,

[pfrazee]

This piqued my interest. IANAL, but surely copyright can't apply for something this small, right? So I did some research, and found there's a Creativity Requirement to US Copyright. It's apparently not very strict, but the uslegal.com explanation does include the following:

Names, titles, and other short phrases do not receive copyright protection. This is because the degree of creativity is simply too minimal to meet the threshold requirement that at least a minimum amount of original expression must exist before copyright protection may attach to a work.

There are however some types of works that are deemed by judges to contain no creativity at all. For example, a mere listing of ingredients or contents, such in a recipe, is considered to be completely lacking in creativity and cannot be protected by copyright. Similarly, telephone directory white pages and other listing of data have also been deemed to lack even minimal creativity.

IANAL, but I'm willing to wager @juliangruber's 1 Mio USD that is-array's copyright wouldn't hold in court.

[allenwb]

https://www.softwarefreedom.org/resources/2007/originality-requirements.html

The originality requirement under both U.S. and E.U. copyright law is minimal, such that courts have ruled computer programs insufficiently original to be eligible for copyright protection in only a very small number of cases. While the originality standard is low, it does exist. In particular, the laws stress that it is a programmer’s expression of some functionality that may be protected by copyright, and not the functionality itself. If code embodies the only way (or one of very few ways) to express its underlying functionality, that code will be considered unoriginal because the expression is inseparable from the functionality. Similarly, if a program’s expression is dictated entirely by practical or technical considerations, or other external constraints, it will also be considered unoriginal. The originality of a program’s functionality is irrelevant to its eligibility for copyright. Code implementing a completely novel algorithm may not be copyrightable due to a dearth of expressive alternatives. Meanwhile, code which behaves identically to other existing programs may be copyrightable because of the original expression of its implementation. A program is also unoriginal to the extent that its expression (but not ideas or functionality) is taken from public domain or other existing code.

[pfrazee]

@allenwb I think that strengthens my argument. This is the portion that I'd focus on:

If code embodies the only way (or one of very few ways) to express its underlying functionality, that code will be considered unoriginal because the expression is inseparable from the functionality.

I'd also mention that the opening line may be misleading.

courts have ruled computer programs insufficiently original to be eligible for copyright protection in only a very small number of cases.

It may be the case that, the court hasn't needed to rule on many pieces of code which are as small as is-array.

[bevacqua]

While the license may make sense for the package itself, which prescribes a bit of effort, thinking that you are entitled to attribution for the code itself -- a one liner you certainly didn't "invent" -- is a waste of everyone's time, to put mildly.

[calvinmetcalf]

hey guys these are some great discussions that should probably be had over on the isArray repo, so I created an issue there (juliangruber/isarray#14) and am going to lock this one