Modern Buffer API polyfill without footguns, working on Node.\+js from 0.\+8 to current.\hypertarget{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26099}{}\doxysection{How to use?}\label{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26099}
First, port all {\ttfamily Buffer()} and {\ttfamily new Buffer()} calls to {\ttfamily Buffer.\+alloc()} and {\ttfamily Buffer.\+from()} API.

Then, to achieve compatibility with outdated Node.\+js versions ({\ttfamily $<$4.\+5.\+0} and 5.\+x {\ttfamily $<$5.\+9.\+0}), use `const Buffer = require(\textquotesingle{}safer-\/buffer').Buffer{\ttfamily in all files where you make calls to the new Buffer API. \+\_\+\+Use}var{\ttfamily instead of}const\`{} if you need that for your Node.\+js version range support.\+\_\+

Also, see the \href{https://github.com/ChALkeR/safer-buffer/blob/master/Porting-Buffer.md}{\texttt{ porting Buffer}} guide.\hypertarget{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26100}{}\doxysection{Do I need it?}\label{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26100}
Hopefully, not — dropping support for outdated Node.\+js versions should be fine nowdays, and that is the recommended path forward. You {\itshape do} need to port to the {\ttfamily Buffer.\+alloc()} and {\ttfamily Buffer.\+from()} though.

See the \href{https://github.com/ChALkeR/safer-buffer/blob/master/Porting-Buffer.md}{\texttt{ porting guide}} for a better description.\hypertarget{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26101}{}\doxysection{Why not $<$a href=\char`\"{}https\+://npmjs.\+com/safe-\/buffer\char`\"{}$>$safe-\/buffer$<$/a$>$?}\label{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26101}
{\itshape In short\+: while {\ttfamily safe-\/buffer} serves as a polyfill for the new API, it allows old API usage and itself contains footguns.}

{\ttfamily safe-\/buffer} could be used safely to get the new API while still keeping support for older Node.\+js versions (like this module), but while analyzing ecosystem usage of the old Buffer API I found out that {\ttfamily safe-\/buffer} is itself causing problems in some cases.

For example, consider the following snippet\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\$ cat example.unsafe.js}
\DoxyCodeLine{console.log(Buffer(20))}
\DoxyCodeLine{\$ ./node-\/v6.13.0-\/linux-\/x64/bin/node example.unsafe.js}
\DoxyCodeLine{<Buffer 0a 00 00 00 00 00 00 00 28 13 de 02 00 00 00 00 05 00 00 00>}
\DoxyCodeLine{\$ standard example.unsafe.js}
\DoxyCodeLine{standard: Use JavaScript Standard Style (https://standardjs.com)}
\DoxyCodeLine{  /home/chalker/repo/safer-\/buffer/example.unsafe.js:2:13: 'Buffer()' was deprecated since v6. Use 'Buffer.alloc()' or 'Buffer.from()' (use 'https://www.npmjs.com/package/safe-\/buffer' for '<4.5.0') instead. }

\end{DoxyCode}


This is allocates and writes to console an uninitialized chunk of memory. \href{https://www.npmjs.com/package/standard}{\texttt{ standard}} linter (among others) catch that and warn people to avoid using unsafe API.

Let\textquotesingle{}s now throw in {\ttfamily safe-\/buffer}!


\begin{DoxyCode}{0}
\DoxyCodeLine{\$ cat example.safe-\/buffer.js}
\DoxyCodeLine{const Buffer = require('safe-\/buffer').Buffer}
\DoxyCodeLine{console.log(Buffer(20))}
\DoxyCodeLine{\$ standard example.safe-\/buffer.js}
\DoxyCodeLine{\$ ./node-\/v6.13.0-\/linux-\/x64/bin/node example.safe-\/buffer.js}
\DoxyCodeLine{<Buffer 08 00 00 00 00 00 00 00 28 58 01 82 fe 7f 00 00 00 00 00 00> }

\end{DoxyCode}


See the problem? Adding in {\ttfamily safe-\/buffer} {\itshape magically removes the lint warning}, but the behavior remains identiсal to what we had before, and when launched on Node.\+js 6.\+x LTS — this dumps out chunks of uninitialized memory. {\itshape And this code will still emit runtime warnings on Node.\+js 10.\+x and above.}

That was done by design. I first considered changing {\ttfamily safe-\/buffer}, prohibiting old API usage or emitting warnings on it, but that significantly diverges from {\ttfamily safe-\/buffer} design. After some discussion, it was decided to move my approach into a separate package, and {\itshape this is that separate package}.

This footgun is not imaginary — I observed top-\/downloaded packages doing that kind of thing, «fixing» the lint warning by blindly including {\ttfamily safe-\/buffer} without any actual changes.

Also in some cases, even if the API {\itshape was} migrated to use of safe Buffer API — a random pull request can bring unsafe Buffer API usage back to the codebase by adding new calls — and that could go unnoticed even if you have a linter prohibiting that (becase of the reason stated above), and even pass CI. {\itshape I also observed that being done in popular packages.}

Some examples\+:
\begin{DoxyItemize}
\item \href{https://github.com/webdriverio/webdriverio/commit/05cbd3167c12e4930f09ef7cf93b127ba4effae4\#diff-124380949022817b90b622871837d56cR31}{\texttt{ webdriverio}} (a module with 548 759 downloads/month),
\item \href{https://github.com/maxogden/websocket-stream/commit/c9312bd24d08271687d76da0fe3c83493871cf61}{\texttt{ websocket-\/stream}} (218 288 d/m, fix in \href{https://github.com/maxogden/websocket-stream/pull/142}{\texttt{ maxogden/websocket-\/stream\#142}}),
\item \href{https://github.com/node-serialport/node-serialport/commit/e8d9d2b16c664224920ce1c895199b1ce2def48c}{\texttt{ node-\/serialport}} (113 138 d/m, fix in \href{https://github.com/node-serialport/node-serialport/pull/1510}{\texttt{ node-\/serialport/node-\/serialport\#1510}}),
\item \href{https://github.com/karma-runner/karma/commit/3d94b8cf18c695104ca195334dc75ff054c74eec}{\texttt{ karma}} (3 973 193 d/m, fix in \href{https://github.com/karma-runner/karma/pull/2947}{\texttt{ karma-\/runner/karma\#2947}}),
\item \href{https://github.com/spdy-http2/spdy-transport/commit/5375ac33f4a62a4f65bcfc2827447d42a5dbe8b1}{\texttt{ spdy-\/transport}} (5 970 727 d/m, fix in \href{https://github.com/spdy-http2/spdy-transport/pull/53}{\texttt{ spdy-\/http2/spdy-\/transport\#53}}).
\item And there are a lot more over the ecosystem.
\end{DoxyItemize}

I filed a PR at \href{https://github.com/mysticatea/eslint-plugin-node/pull/110}{\texttt{ mysticatea/eslint-\/plugin-\/node\#110}} to partially fix that (for cases when that lint rule is used), but it is a semver-\/major change for linter rules and presets, so it would take significant time for that to reach actual setups. {\itshape It also hasn\textquotesingle{}t been released yet (2018-\/03-\/20).}

Also, {\ttfamily safer-\/buffer} discourages the usage of {\ttfamily .alloc\+Unsafe()}, which is often done by a mistake. It still supports it with an explicit concern barier, by placing it under `require(\textquotesingle{}safer-\/buffer/dangereous')\`{}.\hypertarget{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26102}{}\doxysection{But isn\textquotesingle{}t throwing bad?}\label{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26102}
Not really. It\textquotesingle{}s an error that could be noticed and fixed early, instead of causing havoc later like unguarded {\ttfamily new Buffer()} calls that end up receiving user input can do.

This package affects only the files where `var Buffer = require(\textquotesingle{}safer-\/buffer').Buffer\`{} was done, so it is really simple to keep track of things and make sure that you don\textquotesingle{}t mix old API usage with that. Also, CI should hint anything that you might have missed.

New commits, if tested, won\textquotesingle{}t land new usage of unsafe Buffer API this way. {\itshape Node.\+js 10.\+x also deals with that by printing a runtime depecation warning.}\hypertarget{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26103}{}\doxysubsection{Would it affect third-\/party modules?}\label{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26103}
No, unless you explicitly do an awful thing like monkey-\/patching or overriding the built-\/in {\ttfamily Buffer}. Don\textquotesingle{}t do that.\hypertarget{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26104}{}\doxysubsection{But I don\textquotesingle{}t want throwing…}\label{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26104}
That is also fine!

Also, it could be better in some cases when you don\textquotesingle{}t comprehensive enough test coverage.

In that case — just don\textquotesingle{}t override {\ttfamily Buffer} and use `var Safer\+Buffer = require(\textquotesingle{}safer-\/buffer').Buffer\`{} instead.

That way, everything using {\ttfamily Buffer} natively would still work, but there would be two drawbacks\+:


\begin{DoxyItemize}
\item {\ttfamily Buffer.\+from}/{\ttfamily Buffer.\+alloc} won\textquotesingle{}t be polyfilled — use {\ttfamily Safer\+Buffer.\+from} and {\ttfamily Safer\+Buffer.\+alloc} instead.
\item You are still open to accidentally using the insecure deprecated API — use a linter to catch that.
\end{DoxyItemize}

Note that using a linter to catch accidential {\ttfamily Buffer} constructor usage in this case is strongly recommended. {\ttfamily Buffer} is not overriden in this usecase, so linters won\textquotesingle{}t get confused.\hypertarget{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26105}{}\doxysection{«\+Without footguns»?}\label{md_sfcode_node_modules_safer_buffer_Readme_autotoc_md26105}
Well, it is still possible to do {\itshape some} things with {\ttfamily Buffer} API, e.\+g. accessing {\ttfamily .buffer} property on older versions and duping things from there. You shouldn\textquotesingle{}t do that in your code, probabably.

The intention is to remove the most significant footguns that affect lots of packages in the ecosystem, and to do it in the proper way.

Also, this package doesn\textquotesingle{}t protect against security issues affecting some Node.\+js versions, so for usage in your own production code, it is still recommended to update to a Node.\+js version \href{https://github.com/nodejs/release\#release-schedule}{\texttt{ supported by upstream}}. 