Environment–patching vs. non–environment–patching webshims in open source node modules -

Environment–patching vs. non–environment–patching webshims in open source node modules -

short version

would you, web app developer, ok gadget or library requires es5 shims these work in ie7&8? how if included these shims itself, patching global javascript?

long version

when writing open source node module meant run in old browsers ie7 , ie8, should "get" es5 array.prototype.foreach, object.keys , such?

should rely on environment–patching shims (like https://github.com/es-shims/es5-shim) or non–environment–patching shims (like https://www.npmjs.org/package/lodash.keys)?

the original issue is this.

i supplied own reply inconclusive. ask:

what standard this? there mutual policy? are there performance implications meaningful? what other upsides , downsides have not included in answer? are there module maintenance considerations have not taken account?

environment–patching shims

shims https://github.com/es-shims/es5-shim "monkey-patch javascript context contain ecmascript 5 methods can faithfully emulated legacy javascript engine", allowing me write module of es5 methods.

downsides my module code simpler ([1, 2, 3].foreach(function(){});). upsides i must include shims in testing setup, if i'm testing in browsers need them. i "force" module's consumers rely on shims. non–environment–patching shims"

or, "non–shims" lodash.keys or foreach, can used.

upsides i don't need utilize shims in tests. i don't "force" module's consumers utilize shims. downsides

my module's code less pretty, like

var foreach = require("foreach"); foreach([1, 2, 3], function(){});

and can't utilize method, negates possibility of chaining.

node-modules webshim