Update 'buffer' to v5.x

[feross]

Browser support

buffer v5.x drops support for IE8-10.

This allows us to remove the Object implementation and rely on a single
fast implementation based on Typed Arrays, greatly simplifying the maintanence of the
buffer package.

Typed arrays are supported by 97.08% of the U.S. browser market and 92.02% of the
global browser market. Source: http://caniuse.com/#search=typed This number
continues to increase at a steady rate each month.

If IE8-10 support is critical to your web app, you can continue to rely on
browserify v13.

Bundle size

This change shrinks the size of buffer modestly.

55.1kb -> 52.1kb (full size, with comments)
7.0kb -> 6.7kb (minified, gzipped)

Bug fixes

buffer v5.x contains several important fixes including:

• feross/buffer@3639a98
• feross/buffer@4e5c452
• feross/buffer@99491d2

Semver

This should be released as semver major.

[ghost]

This looks good to me. Another option for users would be to depend on the buffer package explicitly or to do:

npm install buffer@^4
browserify -r buffer/:buffer main.js > bundle.js

Users can also include a typed array polyfill: https://github.com/inexorabletash/polyfill/blob/master/typedarray.js

[lorenzos]

Sorry to bother you, but I'm not sure if this means IE8-10 compatibility is compromised for every bundle I build using browserify, of it's only when I use require('buffer') in my app (which I don't). Can you clarify, please?

[ghost]

This patch only affects when your code uses Buffer as a global or when you (or some module you use) does require('buffer').

[feross]

@lorenzos One way to quickly find out of you're using Buffer in your app (even indirectly) is to grep your bundle file for a string that appears in buffer/index.js, like "TYPED_ARRAY_SUPPORT".

If running grep "TYPED_ARRAY_SUPPORT" bundle.js returns nothing then buffer is not included in your bundle.js.

[JDvorak]

Is there a recommended solution for those of us who are targeting audiences restricted to those versions of IE (e.g. certain federal agencies of the USA)? Sticking to v13 is only a viable option if hotfixes can be expected if security problems arise.

[feross]

@JDvorak Browserify usually runs in development (as a build step), not on production servers, so security issues are unlikely.

To continue using an older version of buffer, you can do the following:

$ npm install buffer@4 --save
$ browserify -r buffer/:buffer main.js > bundle.js

[feross]

@JDvorak Out of curiosity, what is the oldest version of IE that government agencies (or your agency) is required to support?

[lorenzos]

@substack @feross Thank you very much for your explanation, I checked with grep, I do not use it.

[JDvorak]

@feross IE8 is typically all that is allowed in groups still restricted to WindowsXP. In the more modernized agencies, you are looking at IE10 or years old "secure" variations of Firefox (best case scenario). On the server side of things, it is all over the place (with substantial use of an increasingly unique fork of Windows Server.) It depends a lot on when the department was established, the mass and inertia of their existing tool chains, and the attitudes of the leadership. A good chunk of the stragglers in browser use statistics are, in all likelihood, probably government work computers.

[tgabi333]

IE10 supports Uint8Array so it should work on IE10, only IE8 and IE9 is left behind.

[tgabi333]

Anyway, IE8 support was dropped when introduced Array.isArray method in 13.0.1.

[JDvorak]

Whew

…

On Mon, Jan 30, 2017 at 5:24 AM Gábor Tóth ***@***.***> wrote: Anyway, IE8 support was dropped when introduced Array.isArray method in 13.0.1. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1678 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAyH-JfACEHOuJQpP_MxrR3mJWCCZs5Lks5rXeSogaJpZM4Ls7yH> .

[feross]

@tgabi333 Unfortunately, IE10's Uint8Array support is buggy, where sometimes slice() returns the wrong length buffer. This gave us trouble to make buffer pass all the tests from Node.js core, so IE10 was actually also using the Object implementation before buffer v5.

I thought about letting IE10 use the typed array implementation now -- since a buggy implementation would be better than none. But IE10 also lacks support for __proto__, which makes it difficult to subclass typed arrays with the methods we need for buffer.

[dwighthouse]

This looks good to me. Another option for users would be to depend on the buffer package explicitly or to do:

npm install buffer@^4
browserify -r buffer/:buffer main.js > bundle.js

@substack How do you accomplish this buffer replacement with buffer 4 when using the Browserify API, not command line? This doesn't appear to work:

var b = browserify({
    entries: testEntry,
    debug: false,
});
b.require('buffer/:buffer');
b.transform('babelify', {
    plugins: [
        ['module-resolver', { root: [rootPath] }],
        'babel-plugin-transform-esm-to-cjs',
    ],
});

It errors out: Error: Cannot find module 'buffer/:buffer'

I'm trying to use Tape with older browsers, which recommends Browserify as the build tool, which thanks to this PR, no longer supports older IEs, as described here.

[ljharb]

One way or another, we need to restore IE support of packages using Buffer by default here. What paths are available?

[dwighthouse]

Also, I hesitate to use the method of adding a global polyfill for Uint8Array or some other type not supported in older browsers, since my library is focused on types themselves. Having these polyfills globally visible could affect the purity of my testing environment, which already falls back when certain types are not detected.

Alternatively, I could increase the complexity of my type testing to check un-polyfillable parts of the types.

[goto-bus-stop]

FWIW, the API equivalent to -r buffer/:buffer is

b.require(require.resolve('buffer/'), { expose: 'buffer' })

[dwighthouse]

@goto-bus-stop Thank you. This code does indeed cause the older version of Buffer to be used. However, it also causes the start of the built file to contain:

"use strict";

require = function () {
...

Since it's in strict mode, and require isn't already defined in the file, this causes an error: Uncaught ReferenceError: require is not defined.

Changing it manually to use the window reference does work, however:

"use strict";

window.require = function () {
...

However, having to manually go in and do string replacements on built files is a bad precedent.

I don't need to expose buffer externally, only do the reference swap as described above. I'm curious why Browserify would create invalid code here.

[goto-bus-stop]

is your build process adding "use strict" somehow? bare browserify should not do that. browserify's code is not invalid, but it doesn't work in strict mode. it does not add "use strict" to bundles because not every node module expects to be run in strict mode. Modules that do expect it already contain "use strict" at the top, and browserify correctly keeps that in each individual module.

I don't need to expose buffer externally, only do the reference swap as described above.

this is indeed a side effect of the current 'solution' for aliasing, and it's not ideal.

[dwighthouse]

@goto-bus-stop You are right. One instance of Babel was adding it.

Ouch, ok.

[ghost]

i have the same problem any solution please.i use truffle drizzle-react-native