refactor: replace Node.js Buffer with Uint8Array or portable replacement #7332
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
@zwave-js-bot pack this |
|
👋 Hey @AlCalzone! |
|
🎉 The packages have been published. |
|
@zwave-js-bot automerge |
zwave-js-bot
approved these changes
Oct 29, 2024
AlCalzone
added a commit
that referenced
this pull request
Oct 30, 2024
### Breaking changes · [Migration guide](https://zwave-js.github.io/node-zwave-js/#/getting-started/migrating/v14) * Replace Node.js Buffer with `Uint8Array` portable replacement class `Bytes` (#7332) * `zwave-js` no longer loops up the package version at runtime (#7344) * Changed some paths to be relative to `process.cwd()` instead of source location (#7345) ### Config file changes * Add Aeotec TriSensor 8 (#7342) ### Changes under the hood * Removed dependency on `fs-extra` in favor of `node:fs/promises` (#7335) * `@zwave-js/config` no longer loops up the package version at runtime (#7343)
AlCalzone
added a commit
that referenced
this pull request
Oct 30, 2024
### Breaking changes · [Migration guide](https://zwave-js.github.io/node-zwave-js/#/getting-started/migrating/v14) * Replace Node.js Buffer with `Uint8Array` portable replacement class `Bytes` (#7332) * `zwave-js` no longer loops up the package version at runtime (#7344) * Changed some paths to be relative to `process.cwd()` instead of source location (#7345) ### Config file changes * Add Aeotec TriSensor 8 (#7342) ### Changes under the hood * Removed dependency on `fs-extra` in favor of `node:fs/promises` (#7335) * `@zwave-js/config` no longer loops up the package version at runtime (#7343)
AlCalzone
added a commit
that referenced
this pull request
Nov 5, 2024
In this release, a lot of the internal API was refactored to decrease interdependencies. Technically this results in a huge list of breaking changes, but most of those should not affect any application, unless very low-level APIs are frequently used. For example, Z-Wave JS UI and Z-Wave JS Server had just two small breaks. In addition, Z-Wave JS is now released as hybrid ESM/CJS packages. ### Breaking changes · [Migration guide](https://zwave-js.github.io/node-zwave-js/#/getting-started/migrating/v14) * `Driver.installConfigUpdates()` now requires the external config directory to be configured (#7365) * Replace Node.js Buffer with `Uint8Array` portable replacement class `Bytes` (#7332) * `zwave-js` no longer loops up the package version at runtime (#7344) * Changed some paths to be relative to `process.cwd()` instead of source location (#7345) * Decouple CCs and messages from host, split parsing and creation, split ZWaveNode class (#7305) ### Config file changes * Add Aeotec TriSensor 8 (#7342) ### Changes under the hood * Decorators have been migrated from the legacy specification to the accepted proposal (#7360) * Transition modules to hybrid ESM/CJS, switch to vitest for testing (#7349) * Removed dependency on `fs-extra` in favor of `node:fs/promises` (#7335) * `@zwave-js/config` no longer loops up the package version at runtime (#7343)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since the beginning of Z-Wave JS, we've been using Node.js's
Bufferclass to manipulate binary data. This works fine, but is not portable, and prevents us from exploring compatibility with other runtimes, or even doing things in the browser, e.g. for flashing controllers or modifying NVM contents.Following Sindre Sorhus's example, this PR replaces the use of
Buffers withUint8Arrays where applicable.In input positions where Z-Wave JS previously accepted
Buffers, this is backwards compatible, asBufferis a subclass ofUint8Array.In output positions however, this is a breaking change. Where applications are affected by this, check if
Buffermethods likereadUInt32BEetc. are actually needed, or if changing the expected type toUint8Arraywould be enough. This is usually the case when just passing the binary data around, or accessing its content by index.In some cases, Z-Wave JS now uses an almost drop-in replacement for Node.js's
Buffer, the newBytesclass exported from@zwave-js/shared. This is a portable subclass ofUint8Arraywith some additions to make its API more (but not 100%) compatible withBuffer. It supports most of theBufferfunctionality likefrom(),concat(),toString()(with limitations),read/write[U]Int...LE/BE.In both cases, if your application really needs a
Bufferinstance, you can simply convertUint8ArrayorBytesto aBufferusingBuffer.from(...).