Buffer() without a new keyword is going to be hard-deprecated soon

Refs: nodejs/node#8169, nodejs/node#7152.

Two options here:

Use the new Buffer API — Buffer.alloc()/Buffer.from()/Buffer.allocUnsafe() (requires a shim for v0.10/v0.12 and older v4.x versions prior to v4.5.0).
Use new Buffer() for the time being — just add the new keyword everywhere. You should manually check that everything is safe in this case, see the links below for more explanation. That might be hard-deprecated at some later point.

More background:

Quick grep (you should better re-check):

browserify-13.1.0.tgz/test/bare.js:34:    ps.stdin.end('console.log(Buffer("ABC"))');
browserify-13.1.0.tgz/test/bare_shebang.js:32:    ps.stdin.end('#!/usr/bin/env node\nconsole.log(Buffer("WOO"))');
browserify-13.1.0.tgz/test/global/buffer.js:1:t.equal(Buffer('xyz').toString('base64'), 'eHl6');
browserify-13.1.0.tgz/test/global/buffer.js:2:t.equal(Buffer('eHl6', 'base64').toString(), 'xyz');
browserify-13.1.0.tgz/test/leak.js:46:    stream.push('t.equal(Buffer("eHl6", "base64").toString(), "xyz")');

The grep above only includes the lines that call Buffer() without the new keyword, if you choose to move to the new API — you should probably also replace new Buffer(…) calls.

😑 . Time to make sure the entire browserify dependency tree is updated, I suppose.

Note: the deprecation was landed and will start printing warnings in Node.js 7.0.

i just installed browserify, nodejs 7.0

its a warning, but is it even running?

> [email protected] babel /Users/Austin/Projects/chicevents
> browserify src/assets/js/functions.js -t babelify --out-file dist/assets/js/app.js --source-maps

(function e(t,n,r){function s(o,u){if(!n[o]){if(!t[o]){var a=typeof require=="function"&&require;if(!u&&a)return a(o,!0);if(i)return i(o,!0);var f=new Error("Cannot find module '"+o+"'");throw f.code="MODULE_NOT_FOUND",f}var l=n[o]={exports:{}};t[o][0].call(l.exports,function(e){var n=t[o][1][e];return s(n?n:e)},l,l.exports,e,t,n,r)}return n[o].exports}var i=typeof require=="function"&&require;for(var o=0;o<r.length;o++)s(r[o]);return s})({1:[function(require,module,exports){
const chic = {
  mobileNav() {
    const mq = window.matchMedia('(max-width: 890px)');
    const header = document.querySelector('header');
    const headerNav = header.querySelector('nav');
    const navUl = headerNav.querySelector('ul');
    const navHamburger = header.querySelector('.hamburger');
    const top = document.querySelector('header .top');
    if (mq.matches) {
      headerFire();
    }

    mq.addListener(() => {
      if (mq.matches) {
        headerFire();
      }
    });

    function headerFire() {
      navUl.classList.add('mobile');

      document.addEventListener('click', event => {
        if (event.target === top) return;
        if (event.target === top.querySelector('.container')) return;

        if (!navUl.classList.contains('mobile')) {
          navUl.classList.toggle('mobile');
          // navUser.classList.toggle('mobile')
          navHamburger.classList.toggle('mobile');
        }
      });
    }

    navHamburger.addEventListener('click', event => {
      navUl.classList.toggle('mobile');
      navHamburger.classList.toggle('mobile');
      event.stopPropagation();
    });
  }
};
chic.mobileNav();

},{}](node:14440) DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or `Buffer.alloc()` instead.
},{},[1]);
onchang

@substack would you accept a PR fixing this issue? I ended up rolling back to node 6 but at some point we'll have to upgrade :/

Is there a list of things that need to be done to get this done? I am willing to help, but a casual glance at the source in the repo has nothing other than the tests usage of Buffer. Is the solution traverse the entire dep tree for usages of the old api?

@wesleytodd

@wesleytodd yeah it looks like it will involve spelunking the dependency tree. One alternative according to @mscdex nodejs/node#9589 (comment) is to change the shebang line in https://github.com/substack/node-browserify/blob/master/bin/cmd.js to read #!/usr/bin/env node --no-deprecation. It's worth noting that fixing the dependencies would at least help other projects that are suffering from the same issue.

Summarizing, I think there are a few ways to resolve this:

modify the browserify command to suppress the deprecation (easy but a hack)
vendor every dependency and make the relevant fixes in the tree (moderate but goes against the spirit of npm)
chase down every dependency, fix every incorrect use, and update the dependencies (hard and we risk facing the same issue next time node "pulls a fast one")

Upon reflection I'm a fan of choice 2, but it will be up to @substack to decide which is the best course of action

@spelunk

@spelunk To be fair, "pulling a fast one" would be if node core simply dropped constructor usage without any warning. The warning is there to give people time to migrate.

I honestly believe the only real solution is to fix the deprecations upstream/downstream, otherwise you're just masking the problem and you will get bitten once the deprecation becomes a removal at some point. At that time, things will probably be even worse because you'll be scrambling to fix actual broken dependencies.

@mscdex

I agree with @mscdex on the way forward.

Side note, it was actually @substack that called it "pulling a fast one" :)

Did we found a bad dependency or we need help here?

@ai

@ai you can find the first offending use case by running browserify using the --trace-warnings option:

$ touch foo.js
$ node --trace-warnings `which browserify` foo.js >/dev/null
(node:18812) DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or `Buffer.alloc()` instead.
    at Buffer (buffer.js:79:13)
    at DestroyableTransform.write [as _transform] (/usr/local/lib/node_modules/browserify/node_modules/browser-pack/index.js:53:32)
    at DestroyableTransform.Transform._read (/usr/local/lib/node_modules/browserify/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:159:10)
    at DestroyableTransform.Transform._write (/usr/local/lib/node_modules/browserify/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:147:83)
    at doWrite (/usr/local/lib/node_modules/browserify/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:313:64)
    at writeOrBuffer (/usr/local/lib/node_modules/browserify/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:302:5)
    at DestroyableTransform.Writable.write (/usr/local/lib/node_modules/browserify/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:241:11)
    at DestroyableTransform.ondata (/usr/local/lib/node_modules/browserify/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:531:20)
    at emitOne (events.js:96:13)
    at DestroyableTransform.emit (events.js:188:7)

The offending line from /usr/local/lib/node_modules/browserify/node_modules/browser-pack/index.js is

        if (first) stream.push(Buffer(prelude + '({'));

I think it was fixed in the source repo: browserify/browser-pack@c91b816 , so in this case it just comes down to @substack publishing a new version of the module. Hopefully that's the only offending case

@spelunk

@spelunk thanks for --trace-warnings argument, never know about it.

I pinged browser-pack developers browserify/browser-pack#76

Yeap, I agree that warning is not a error.

Sorry, I thought that you could release it quick in patch release :).

@ai

@substack @ai changing the shebang line of bin/cmd.js to call node with the --node-deprecation argument suppresses the message without having to go through and change all of the dependencies:

--- a/bin/cmd.js
+++ b/bin/cmd.js
@@ -1,4 +1,4 @@
-#!/usr/bin/env node
+#!/usr/bin/env node --no-deprecation

This has the added benefit of suppressing future messages.

Navigation Menu

Repository navigation

`Buffer()` without a `new` keyword is going to be hard-deprecated soon #1616

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Buffer() without a new keyword is going to be hard-deprecated soon #1616

Description

Activity

terinjokes commented on Aug 19, 2016

ChALkeR commented on Aug 25, 2016

theskillwithin commented on Nov 4, 2016

spelunk commented on Nov 13, 2016

wesleytodd commented on Nov 13, 2016

spelunk commented on Nov 13, 2016

mscdex commented on Nov 13, 2016

wesleytodd commented on Nov 13, 2016

ai commented on Nov 21, 2016

spelunk commented on Nov 21, 2016

ai commented on Nov 21, 2016

ai commented on Nov 22, 2016

spelunk commented on Nov 22, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`Buffer()` without a `new` keyword is going to be hard-deprecated soon #1616