PolyFull - enhance js capabilities

This isn't polyfilling, it's monkey patching. Polyfills are to add support for features that are in the spec but not yet supported by all environments. Polyfills are considered safe, because all they're doing is improving consistency between the different environments.

Monkey patching, however, is stuff that will almost certainly never be in the spec, but might clash with other things added to the spec later on, or with other rogue libraries that decide to monkey patch stuff, because it's all global.

There is one way and only one way to monkey patch safely: by using unique symbols:

// my-fancy-lib/index.js

export const remove = Symbol('remove')

Array.prototype[remove] = function(val) {
    const idx = this.indexOf(val)

    if (idx !== -1) this.splice(idx, 1)

    return this
}

// my-app/src/my-lib-consumer.js

import { remove } from 'my-fancy-lib'

const arr = [1, 2, 3]

arr[remove](2)[remove](3) // [1]

That works fine and won't pollute any global namespaces, because the symbol used to access the new method is only accessible by importing it directly from the library (or by doing something convoluted like Object.getOwnPropertySymbols(Array.prototype).find(({ description }) => description === 'remove'), which a consumer of your library wouldn't plausibly do by mistake).

As shiny and cool as symbols are, however, in my opinion it's better not to monkey patch at all, and instead to just use plain old functions that take the target array as a parameter. If you want to keep the nice left-to-right syntax you get from method chaining, you can implement the API with higher-order functions and use a pipe function to compose them:

// my-fancy-lib/index.js

export const pipe = (initialVal, ...fns) => fns.reduce((val, fn) => fn(val), initialVal)

export const remove = (val) => (arr) => {
    const idx = arr.indexOf(val)

    return [
        ...arr.slice(0, Math.max(idx, 0)),
        ...arr.slice(idx + 1),
    ]
}

// my-app/src/my-lib-consumer.js

import { pipe, remove } from 'my-fancy-lib'

const arr = [1, 2, 3]

pipe(arr, remove(2), remove(3)) // [1]

This version also has the added advantage of not mutating the original array.

I see LUKESHIRU got a bit dogmatic here. But someone had to be 1st 😀 Anyway, I don't want to get involved into that discussion. I believe everyone can decide. But I remember SugarJS has nice long article about the risks, how to deal with them and alternatives to choose in their own library. Nice reading everyone :) sugarjs.com/extending/

Great care should be taken when extending the built in types. The potential to break stuff is very high

at the first line of README you can find this:

warning THIS IS INTENDED TO USE ONLY IN FINAL APPLICATIONS.

if you use this in library, any other applications that use your library will have polyfull injected as well.

if you use it in final application (whatever it is) you should be fine.

if you use with another library that change native object, some trouble can occurs if there is name collisions.

This is intended to use "alone" or at least with another that have no overlaps.

Most of this stuff is available in lodash without the pitfalls of having so many global functions. This is really bad practice, nobody should use this.

Also nobody else mentioned, besides all the other problems, you can't tree-shake away any of the methods you aren't using.