Releases: ethersphere/bee-js
@ethersphere/bee-js v3.3.2
This is another small release that brings support for Bee 1.5.0 and a few small improvements.
🔌 Node endpoint
The Bee 1.5.0 introduced new mode called ultra-light mode. This mode has been added to the existing BeeModes
.
🧱 EcmaScript Modules
The bee-js v3.3.0 introduced support for ES Modules. In 3.3.2 we include several fixes to resolve some of the reported issues and broken builds.
Bug Fixes
@ethersphere/bee-js v3.3.1
This is a patching release that targets especially issues discovered thanks to the introduction of the ESM hybrid build. The main change is that if you want to use the function Utils.readableWebToNode()
in browser then you have to polyfill stream
package with your bundler.
Major changes of the last 3.3.0 release are:
🧱 EcmaScript Modules support
We plan to migrate our bee-js package to ES Modules (see the issue for more info) when Node v12 will reach its end-of-life (on 30th of April). With this release, we are starting a transition period by supporting both ES Modules and CommonJS builds. Please start migrating your applications to the ESM stack otherwise, you won't be able to upgrade bee-js after we drop support for CommonJS.
❓ Is supported version?
Since we are in a fast-paced environment where Bee's versions can be incompatible with each other, it is important that in your application you check whether the Bee that you connect to has the correct version that you expect and support (through bee-js
).
Untill now we had the isSupportedVersion()
function that indicated if the Bee node version is not matching the one that bee-js
was tested and built against. This implementation has its downside because it is very strict and if for example there is a small Bee's release that patches only something internal and does not touch the API, which means that the bee-js
should be compatible, you will still get a false
with this check.
Except for Bee's version itself, there are two other versions that version the Bee endpoint's API and the Bee Debug endpoint's API. We have decided to implement methods that do compatibility checks using these versions and hence should be more relaxed towards Bee's small patches but might pose some risk if some change will be unnoticed and API versions not bumped accordingly.
These methods are:
BeeDebug.isSupportedExactVersion()
- renamedisSupportedVersion
which is now deprecatedBeeDebug.isSupportedMainApiVersion()
which checks compatibility only for the main Bee endpointBeeDebug.isSupportedDebugApiVersion()
which checks compatibility only for the Bee Debug endpointBeeDebug.isSupportedApiVersion()
which checks compatibility for both endpoints
The compatibility is checked using the major versions of the API. If you would like to make your own assertions you can get all the versions (both from Bee itself and the one that bee-js should support) using the method BeeDebug.getVersions()
Bug Fixes
- add js suffix in imports for esm support with babel (#562) (62489aa)
- create minified browser bundle for release (#549) (b92fdb0)
- drop readable stream (#565) (3e36ccc)
- exposing ky options (#553) (085c565)
- making readable-stream optional (#556) (4983fdc)
- rename the browser bundle in order not to break unpkg.com (#552) (7076d94)
- use default import styles for esm compatibility (#550) (90aaf7b)
@ethersphere/bee-js v3.3.0
This is a smaller update with two main changes.
🧱 EcmaScript Modules support
We plan to migrate our bee-js package to ES Modules (see the issue for more info) when Node v12 will reach its end-of-life (on 30th of April). With this release, we are starting a transition period by supporting both ES Modules and CommonJS builds. Please start migrating your applications to the ESM stack otherwise, you won't be able to upgrade bee-js after we drop support for CommonJS.
❓ Is supported version?
Since we are in a fast-paced environment where Bee's versions can be incompatible with each other, it is important that in your application you check whether the Bee that you connect to has the correct version that you expect and support (through bee-js
).
Untill now we had the isSupportedVersion()
function that indicated if the Bee node version is not matching the one that bee-js
was tested and built against. This implementation has its downside because it is very strict and if for example there is a small Bee's release that patches only something internal and does not touch the API, which means that the bee-js
should be compatible, you will still get a false
with this check.
Except for Bee's version itself, there are two other versions that version the Bee endpoint's API and the Bee Debug endpoint's API. We have decided to implement methods that do compatibility checks using these versions and hence should be more relaxed towards Bee's small patches but might pose some risk if some change will be unnoticed and API versions not bumped accordingly.
These methods are:
BeeDebug.isSupportedExactVersion()
- renamedisSupportedVersion
which is now deprecatedBeeDebug.isSupportedMainApiVersion()
which checks compatibility only for the main Bee endpointBeeDebug.isSupportedDebugApiVersion()
which checks compatibility only for the Bee Debug endpointBeeDebug.isSupportedApiVersion()
which checks compatibility for both endpoints
The compatibility is checked using the major versions of the API. If you would like to make your own assertions you can get all the versions (both from Bee itself and the one that bee-js should support) using the method BeeDebug.getVersions()
Features
@ethersphere/bee-js v3.2.0
This is after some time a bigger update that brings some new goodies from Bee 1.4.1 version and improved error handling and support.
↔️ Direct upload support
Bee introduced direct upload mode, where Bee directly pushes the data to the network instead of the intermediate step of locally saving the data and then syncing it with the network. You can enable this behavior by passing deferred = false
into UploadOptions
interface. When you enable this mode the Promise
returned by the upload methods will resolve only once the data is uploaded and synchronized with the network so if you use timeouts you should adjust those base on the size of data you upload.
Currently, the direct upload mode is by default turned off, but it is a plan in the future to enable this behavior by default!
⁉️ Error handling
Now BeeResponseError
and BeeRequestError
instances contain information about the request (and if applicable also response) that triggered the Error. Also, it has improved for non-JSON responses that were causing unclear errors.
⚠️ Deprecations
In this release, there are two changes in Interface's names that are non-breaking as there are backward compatible aliases, but these aliases will be removed with the next breaking change.
- Interface
DebugPostageBatch
was renamed toPostageBatch
- Interface
NodesInfo
was renamed toNodeInfo
Features
- direct upload support (#504) (e05fae7)
- exposing request and response configuration on BeeResponseError (#517) (7448958)
- node 17 support (#507) (c9e727a)
Bug Fixes
@ethersphere/bee-js v3.1.0
This is another small release that brings support for Bee 1.4.1 and a few small improvements
🔌 Node endpoint support
The Bee 1.4.1 release brought a new endpoint on Debug API called /node
which provides information about in what mode the Bee node runs (such as dev mode, light mode, or full mode or information about gateway mode).
🔗 Chunk endpoint supports
We used chunk endpoints internally in bee-js but now we have decided to expose them for your usage as well.
∵ Stamp usage utility functions
In order to calculate the usage of a postage stamp (eq. percentage in form of a number between 0 and 1) we have added a small utility function that calculates it called getStampUsage()
.
Features
- exposing chunk functionality (#472) (b121dcb)
- node endpoint support (#479) (11731d3)
- stamp usage utility function (#470) (b53edd1)
Bug Fixes
@ethersphere/bee-js v3.0.0
This is a small release in size, but big on impact. It is a breaking release thanks to breaking changes introduced in Bee 1.4.
⚠ BREAKING CHANGES
- dropping postage stamps methods from
Bee
class (#458)
Features
- dropping bee class postage stamps methods (#458) (98afdcd)
- openapi versions in
/health
endpoint and methods (#459) (98afdcd)
@ethersphere/bee-js v2.1.1
@ethersphere/bee-js v2.1.0
This release is a compatibility release with Bee 1.2.0 release, which brings few new features.
Is retrievable? support
The new method bee.isReferenceRetrievable()
allows you to check whether the data represented by a reference is present in the network. This is part of the Stewardship endpoint, which also allows you to reupload the data that you have locally available (pinned).
🏷 New Postage Batch methods
There is a new method beeDebug.topUpBatch()
, that allows you to top-up the amount of existing batch, effectively prolonging its lifetime.
Moreover, there is also a new method beeDebug.diluteBatch()
that increases the depth of a batch, effectively extending the number of chunks that the batch can stamp and lowering the lifetime of a batch.
📨 PSS Target limit increase
makeMaxTarget
, then the time of sending a PSS message will increase! Consider using your own criteria based on your use-case.
Features
- increased max pss target limit (#430) (3134c50)
- is reference retrievable support (#425) (76601f8)
- topup and dilute batch methods (#424) (7bf2135)
Bug Fixes
Reverts
@ethersphere/bee-js v2.0.0
This is our first major version bump as we did a big revamp of bee-js
internals and fixed a few things and shortcomings that required breaking changes.
🤖 HTTP client swap (timeout and retries support)
In the JS browser ecosystem, there are two main HTTP clients: old XMLHttpRequest (XHR) API and new modern fetch
API.
We originally used axios
library that employs the XHR client, but XHR is old and will not get any new features as it is superseded with fetch
API that is actively developed by the WHATWG group, and hence it has its limitations. Many limitations can be overcome using polyfills etc. but a hard stop is networking that only browsers decide what to allow (usually based on the specification). In the case of XHR the limitation is streaming support.
We have therefore decided to use fetch
based library ky
that supports streaming downloads and hopefully in close future will support also streaming uploads (see whatwg/fetch#966, there is also already functional experiment that enables this in Chrome). fetch
is also more future-proof.
This change, unfortunately, does not come without a cost and that is support for tracking upload progress, that fetch
still does not have (if interested please comment on the relevant whatwg/fetch#607 issue to raise importance).
If this feature is crucial for you, we have devised a workaround thanks to @mattiaz9, which is demonstrated in our example upload-progress
.
This change unfortunately is breaking as we originally exposed AxiosOptions
on our API. We have refactored this into more generic HTTP options that should be more future-proof. Thanks to ky
we also now have support for retries of failed requests (only for non-POST
requests, defaults are seen here) and timeouts. Both are possible to set generally for the Bee
instance and/or override it for each method call.
🎏 Streaming revamp
As part of the HTTP client revamp, we had a deeper look at how we handle streams. In the JS land, there are two main types of streams the NodeJS Readable
and the browser WHATWG ReadableStream
. As our design mindset is browser-first and polyfill the rest in NodeJs, we have unified all returned streams into the WHATWG ReadableStream
no matter what platform you are on. Most probably you will want to use NodeJs Readable
on NodeJs platform, so we have included utility function readableWebToNode
that converts WHATWG stream into NodeJs. There are also more stream-related utility functions that you can check out.
For stream inputs, we accept both types of streams and convert them internally.
⏎ Upload results refactor
One of our short-coming was dropping the returned object from upload methods in favor of the simple string Reference
. Later on, we discovered that there is actually a need to return more information from upload operations because Bee automatically creates a Tag for each upload that we could return. Hence we have introduced back UploadResult
interface that all the upload methods will now return.
🫓 Utility namespace flatting and filtering
We have merged all the Utils.*
namespaces directly into Utils
and we have filtered out the functions only to those that make sense to expose in order to minimize the public API and possible future breaking changes.
🗾 uploadCollection()
method
We have introduced new uploadCollection
method that is more flexible in uploading collection if you do not want to use our convenience methods like uploadFilesFromDirectory()
or uploadFiles
. This new method accepts the Collection<Uint8Array | Readable>
interface.
⚠ BREAKING CHANGES
- Requests made by
bee-js
are now reported withUser-Agent: bee-js/<<bee-js's version>>
(#390) Utils.setDefaultHeaders()
was removed in favor ofBee
/BeeDebug
instance's optiondefaultHeaders
(#390)- Hooks (#390)
Utils.hooks.*
was removed in favor ofBee
/BeeDebug
instance's optionsonRequest
andonResponse
- Hooks now pass only metadata of the requests and not the payload
- All returned streams are now of
WHATWG ReadableStream
. If you need NodeJS's Readable you can useUtils.readableWebToNode()
utility function. (#390) - All
axiosOptions
were removed from those methods that supported it (for examplebee.downloadReadableData()
,bee.reuploadPinnedData()
,UploadOptions
does not haveaxiosOptions
property anymore) (#390) - Unfortunately
fetch
does not support tracking of upload progress (like XHR/axios supported with theonUploadProgress
). Please see our exampleupload-progress
for work-around. (#390) - All upload methods now returns
UploadResult
interface (#408) bee.pssSend()
now throws error if the specified target exceeds maximal value. UseUtils.makeMaxTarget()
that will give you the max target that Bee accepts. (#384)Utils
namespace is flattened and limited on the functions (#395)
Other changes:
- All upload methods that used to accept NodeJS's Readable now accept both NodeJS and WHATWG Readable(Stream).
- Usage of ReadableStreams in a browser is now possible. Be aware that real support for streaming browsers has only for download, but not upload. When Readable is passed to upload methods it is first fully buffered before making the request.
Features
- HTTP request options is possible to override per method call (#411) (9eac5cd)
- return
UploadResult
for upload methods (#408) (e58b8e8)
Bug Fixes
- pss target length verification (#384) (fd032a8)
- remove check for pinned content in reupload (#412) (6032a22) - thanks @ldeffenb for reporting this!
Code Refactoring
@ethersphere/bee-js v1.2.1
This is a small patch release that fixes wrongly reporting incompatible version with Bee 1.1.0 builds for Mac and Windows. Related to ethersphere/bee#2451