| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
buffer v5 requires Uint8Array to be defined. apparently it is not defined by default in node v0.10.
|
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? |
Sorry, something went wrong.
|
This patch only affects when your code uses Buffer as a global or when you (or some module you use) does require('buffer'). |
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
@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 |
Sorry, something went wrong.
|
@JDvorak Out of curiosity, what is the oldest version of IE that government agencies (or your agency) is required to support? |
Sorry, something went wrong.
|
@substack @feross Thank you very much for your explanation, I checked with grep, I do not use it. |
Sorry, something went wrong.
|
@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.
|
Sorry, something went wrong.
|
IE10 supports Uint8Array so it should work on IE10, only IE8 and IE9 is left behind. |
Sorry, something went wrong.
|
Anyway, IE8 support was dropped when introduced Array.isArray method in 13.0.1. |
Sorry, something went wrong.
|
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>
.
|
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
@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. |
Sorry, something went wrong.
|
One way or another, we need to restore IE support of packages using Buffer by default here. What paths are available? |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
FWIW, the API equivalent to -r buffer/:buffer is b.require(require.resolve('buffer/'), { expose: 'buffer' }) |
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
|
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.
this is indeed a side effect of the current 'solution' for aliasing, and it's not ideal. |
Sorry, something went wrong.
|
@goto-bus-stop You are right. One instance of Babel was adding it. Ouch, ok. |
Sorry, something went wrong.
|
i have the same problem any solution please.i use truffle drizzle-react-native |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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:
Semver
This should be released as semver major.