buf: move buffer.slice to runtime deprecation

[hainenber]

Resolves #60813

I have:

• Included tests for any bug fixes or new features.
• Updated documentation if relevant.

Move Buffer.prototype.slice() to runtime deprecation class. This shouldn't affect existing userland since it's only emitted warning.

[nodejs-github-bot]

Review requested:

• @nodejs/userland-migrations

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.55%. Comparing base (7fd3688) to head (cab08f4).
⚠️ Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #60820      +/-   ##
==========================================
- Coverage   88.56%   88.55%   -0.01%     
==========================================
  Files         703      703              
  Lines      208254   208266      +12     
  Branches    40156    40162       +6     
==========================================
- Hits       184430   184427       -3     
- Misses      15828    15839      +11     
- Partials     7996     8000       +4     

Files with missing lines	Coverage Δ
lib/_http_server.js	97.18% <100.00%> (+0.07%)	⬆️
lib/buffer.js	100.00% <100.00%> (ø)
lib/internal/streams/readable.js	96.20% <100.00%> (-0.01%)	⬇️
lib/internal/test_runner/runner.js	92.81% <100.00%> (ø)
lib/zlib.js	98.27% <100.00%> (ø)

... and 49 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[hainenber]

I think there are still remaining buffer.slice() usages in the codebase but not detected/caught by failed tests and snapshots. Having said that, until it's flagged as EoL, the method should still be functioning and at worst fails snapshots in userlands (I haven't thought of other possible scenarios).

There's a failed CI step but it's CPU-based so I think it'd be varied by GHA fleet.

[panva]

I have concerns about moving DEP0158 to runtime deprecation. The current approach will create a very confusing and messy experience for users, particularly in library ecosystem scenarios.

When users pass Buffer instances to libraries that are written to accept and expect Uint8Array, those libraries may legitimately call .slice() on the input. If we add a runtime deprecation warning for Buffer.prototype.slice(), users will see warnings that appear to originate from the library they're using, even though:

• The library is doing nothing wrong
• The library is correctly using standard TypedArray.prototype.slice() semantics
• The library author has no control over whether users pass Buffer instances

This creates a confusing attribution problem where deprecation warnings will cause library maintainers unnecessary reports and support burden.

Instead of deprecating Buffer.prototype.slice() with the intent to remove it, we should deprecate the current behavior with the intent to align it with TypedArray.prototype.slice() in a future major version.

Is there a path forward we can take towards that goal?

As an aside, once it'd be removed wouldn't TypedArray.prototype.slice() just take its place?

[hainenber]

Might be we can lower the deprecation level a bit to Application to limit the radius to userland?

[Renegade334]

When users pass Buffer instances to libraries that are written to accept and expect Uint8Array, those libraries may legitimately call .slice() on the input.

IMO this is the strongest reason to progress this deprecation.

Buffers are currently unsafe to pass to Uint8Array-accepting libraries that call .slice, in a way that isn't immediately apparent to the caller: the return values of both prototypes' slice methods are the same in terms of byte values, but the underlying memory behaviour is different. A library function that calls .slice rather than .subarray on a typed array is most often doing so because the original buffer view remains valid, and is not expecting the sliced result to reference the same memory and potentially mutate it in the future.

That being said, it'd probably be a major headache unless application-only, similar to new Buffer().