Rule proposal: no-buffer-constructor

In the upcoming Node.js v6 release, the existing Buffer() constructors are being soft-deprecated (docs-only deprecation) and replaced with new Buffer.alloc(), Buffer.allocUnsafe() and Buffer.from() alternatives. I am adding a rule to Node.js’ own eslint configuration to flag uses of the deprecated constructors (see: https://github.com/nodejs/node/pull/5740). The point has been raised that it may be worthwhile upstreaming this rule so that it can be of benefit to the ecosystem as a whole. Currently the rule is pretty simplistic and can be made a bit more robust if necessary.

The rule catches uses of the Buffer() constructor either as new Buffer(...) or simply Buffer(...) (without the new) and suggests using one of the new constructors instead.

If it is worthwhile, I can open a pull request to submit the rule here.

[feross]

I think preventing usage of deprecated APIs which have security implications is probably one of the few cases where it makes sense to add another node-related rule in ESLint core. Preventing the anti-pattern where Buffer(var) accidentally returns uninitialized program memory fits in with other similar ESLint rules that prevent unintended program behavior.

Even if it’s not included in eslint:recommended, I believe the mere inclusion in ESLint will have a significant effect on the visibility of the rule.

I’m really keen to see community tooling (like standard and hopefully ESLint) step up and discourage soon-to-be-deprecated Node.js APIs. That way, when deprecation finally happens most modules are upgraded and it’s a lot less painful for the community.

That said, I understand the maintenance burden that adding another rule entails, so I’ll respect the team’s decision. 👍

[not-an-aardvark]

I’ll champion this.