* add nfts_by_issuer data type
* update HISTORY.md
* update HISTORY.md
* added to index and change field name
* change to added in history
* reformat change in history
* reformat history on bfts_by_issuer
* add include_deleted field
* update history
* fix an error in histroy
* changed comments
---------
Authored-by: Kassaking <kassaking7@gmail.com>
* update Paths snippet test: perform prerequisite test setup within the test, remove dependence on theexternal state of testnet
* remove bridge snippet test, the sidechain has been shut down
* [FIX] Update paths snippet. Replace RipplePathFind with PathFind RPC (fixes#2385)
* update Paths snippet test: perform prerequisite test setup within the test, remove dependence on theexternal state of testnet
* fix lint errors
* remove bridge snippet test, the sidechain has been shut down
* [FIX] Update paths snippet. Replace RipplePathFind with PathFind RPC (fixes#2385)
* feat: Upgrade to Node 18 and remove cross-fetch (#2678)
BREAKING CHANGE: fetch now relies on the native javascript environment in browsers and node.js
Co-authored-by: justinr1234 <justinr1234@gmail.com>
* add apiVersion support to requests and AccountInfoResponse v1/v2 types
* fix submitAndWait signature
* update docker container README
* update tests
* fix apiVersion param in wrong position of Client.request
* add integ tests
* update HISTORY.md
* fix request.api_version
* update RIPPLED_DOCKER_IMAGE to use v2.1.0
* refactor Client.request signature
* update rippled docker image
* fix Client.requestAll
* update rippled docker image to use v2.1.1
* update README
* use import type
* fix faucet; unrelated to PR
* add api_version v2 support and set as default while providing support for v1
* refactor: add apiVersion to Client
* resolve errors
* use DeliverMax for isPartialPayment check
* update fixtures
* resolve lint errors
* add API v1 support for isPartialPayment
* update CONTRIBUTING
* update accountTx JSDoc
* revert deleted JSDoc comments in accountTx
* update JSDoc for account_info response
* only use client.apiVersion in Client.request()
* add ledger_hash
* remove API v1 comment from v2 model
* update meta_blob JSDoc
* delete second AccountTxRequest matching
* add close_time_iso
* set close_time_iso as optional field
* add meta_blob to BaseResponse
* Revert "add meta_blob to BaseResponse"
This reverts commit 89794c629dc515915e28752d7c2552bfeab266a3.
* use DEFAULT_API_VERSION throughout call stack
* improve JSDoc explanation of ledger_index
* remove this.apiVersion from getLedgerIndex
* refactor Client.request()
* refactor RequestManger.resolve()
* add TODO to fix TxResponse type assertion
* use @category ResponsesV1 for API v1 types
* refactor accountTxHasPartialPayment()
* remove TODO
* add nfts_by_issuer data type
* update HISTORY.md
* update HISTORY.md
* added to index and change field name
* change to added in history
* reformat change in history
* reformat history on bfts_by_issuer
---------
Authored-by: Kassaking <kassaking7@gmail.com>
* generateSeed() update: If no algorithm is specified, use ed25519 algorithm by default.
This causes breakge in downstream dependencies such as Account class. Account.familySeed makes use of generateSeed
* update Migration guide: info about the changed behavior
* updates to MIGRATION guide -- suggestions from jackson mills
---------
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
* rectify the flag name tfNoRippleDirect
* Update th History.md file
* use "Breaking Changes" heading in the API Changelog
* Update HISTORY.md
---------
- Removes need for bundlers to polyfill the `Buffer` class. `UInt8Array` are used instead which are native to the browser and node.
- Reduces bundle size 7.1kb gzipped and eliminates 4 runtime dependencies: `base-x`, `base64-js`, `buffer`, and `ieee754`.
BREAKING CHANGE: All methods that previously took a `Buffer` now accept a `UInt8Array`.
---------
Co-authored-by: Jackson Mills <jmills@ripple.com>
docs: update react-native setup guide
With 3.0 less polyfill work is required and after Buffer is removed as a
dependency there will be even less.
In the future we may add `react-native` entries to `@xrpl/isomorphic`
`package.json` files which might remove the need for these extra steps.
- Convert tests to typescript
- Update type definitions causing errors in tests
- `makeParser` to accept a `Buffer` in addition to `string`
- `SerializedType` constructor allows not passing in a byte array
- `Comparable` is now a generic type so that it allows `compareTo`
methods to take more that the type itself. Example: `Uint64.compareTo`
can accept `number`
- Update tests to use jasmine compatible functions
- Switching from `test` to `it`.
- Updated test checking if coretypes all implement SerializedType
- Import fixtures directly instead of using `loadFixture` utility
- Remove importing of `buffer/` explicitly. It was throwing off type
checking in tests. Buffer is going away in a future PR anyway.
- Fixed `npm run clean` not clearing `.tsbuildinfo` files for keypairs
- Remove unused account-tx-transactions.db. It was likely used in the
past to test historical ledgers.
- Update tests to use jasmine compatible functions. This means removing `toThrowErrorMatchingInlineSnapshot` and manually removing indention to compare some of the complexly formatted error messages.
- Remove usages of `assert` library in keypairs tests.
refactor: remove `import *` where able to
BREAKING CHANGE: Moved all methods that were on `Utils` in
`@xrplf/secret-numbers` are now individually exported. This affects:
- Utils.randomEntropy,
- Utils.randomSecret
- Utils.entropyToSecret
- Utils.secretToEntropy
- Utils.calculateChecksum
- Utils.checkChecksum
- Utils.parseSecretString
refactor: type Transaction to include all tx
BREAKING CHANGE: `Transaction` type has been redefined to include all
transactions and `SubmittableTransaction` was created to define the old
value. The following functions which only handle transactions to be
submitted now use `SubmittableTransaction`:
* `Client.autofill`
* `Client.submit`
* `Client.submitAndWait`
* `Client.prepareTransaction`
* `getSignedTx`
* `isAccountDelete`
Reduces filesize by 3kb minified and gzipped or 2.8% and reduces bundler
config steps.
- Move `WSWrapper` to `@xrpl/isomorphic` to remove the need to add
mapping of `ws` to `WSWrapper` file in bundler configs
- Switch to `eventemitter3` which is smaller than `events` by almost
1kb and will not require a mapping to node's `events` in `vite`
bundling. `webpack` always automatically maps it.
- max listeners is not a thing for `eventemitter3` so we do not
need to set it to `Infinity`. `ws` uses the native event emitter which
does still need that to be set.
- Remove `eventemitter2` which was only used in tests and was replaced
with `eventemitter3`
BREAKING CHANGE: Config for frontend bundlers has changed for `ws`.
Switch to using `@noble/hashes`, `@noble/curves`, `@scure/base`,
`@scure/bip32`, and `@scure/bip39`. This replaces `crypto` polyfills
(such as `crypto-browserify`), `create-hash`, `elliptic`, `hash.js`,
`bn.js` (both versions), and their many dependencies. This also means
there are 33 less dependencies downloaded when running a fresh
`npm install` and will make the project much easier to maintain.
This reduces the bundle size by 44% (82kb minified and gzipped) over
the current 3.0 branch as well as reducing the amount of configuration
required to bundle.
Closes#1814, #1817, #2272, and #2306
Co-authored-by: Caleb Kniffen <ckniffen@ripple.com>
- Remove tests from `ripple-keypairs` that exclusively tested
`rippled-address-codec`. The tests in `codec.test.ts` and
`xrp-codec.test.ts` are all present and accounted for in
`packages/ripple-address-codec/test/xrp-codec.test.ts`.
- Update `package-lock.json` after the rebase with main
- Remove references to `decimal.js` in the documentation
* add missing entry for `bignumber.js` to `ripple-binary-codec`
This will clean up the diff for #2273
Update tests to use jasmine compatible functions.
This means changing `test` to `it`, `toStrictEqual` to `toEqual` (which
is still strict), `toThrowError` to `toError`, and updating the param
for toError to pass an `Error` object.
Remove the need to specify --single-run.
This is done by properly deleting all build files.
Package-lock was due to it not reflecting the license of
@xrplf/secret-numbers. This was fixed by running `npm i`.
Add type for metadata for specific transactions(`Payment`, `NFTokenMint`, `NFTokenCreateOffer`, `NFTokenAcceptOffer`, `NFTokenCancelOffer`)
Closes#2316
- Add `xrpl-secret-numbers` by @WietseWind to the mono repo.
- `unpkg` and `jsdelivr` support was simplified by adding fields to package.json.
- Unit tests run in a browser and node.
BREAKING CHANGES:
- `xrpl-secret-numbers` is now `@xrplf/secret-numbers`.
- Changed the bundled file produced changed from `dist/browerified.js` to `build/xrplf-secret-numbers-latest.js`.
- Bundle variable is `xrplf_secret_numbers` instead of using browserify's loader.
- If using CDN instructions in README will need to update to `https://cdn.jsdelivr.net/npm/@xrplf/secret-numbers`
Making this library part of the monorepo was discussed in #1788. This solves several problems with the upcoming `xrpl.js@3.0`.
`xrpl-secret-numbers` has a dependency of `ripple-keypairs` and `xrpl` has a depenendecy on `xrpl-secret-numbers`. This means that any change would require a separate release of `ripple-keypairs`, then a release of `xrpl-secret-numbers`, followed by `xrpl`. Now they can be released all at once
In 3.0 we eliminated the need for many polyfills like `util`, `assert`, and soon to be `buffer` (after noble libs PR is merged). `xrpl-secret-numbers` still needs those. This will also eliminate them and anytime similar changes in the future will be much easier. This further reduces the bundle size of 3.0 branch by over 10% as well as reducing bundler setup.
- Switch files to typescript
- Add missing types in test files
- Change how the codec functions were imported. They now count towards the "% Funcs" calculation, increasing it from 75% to 100%.
- Lint test files
* fix: make docs not output confusing information in xrpl client
---------
Co-authored-by: Jackson Mills <jmills@ripple.com>
Co-authored-by: Caleb Kniffen <ckniffen@ripple.com>
Removes the testing polyfills by using jasmine and not jest in the
browser. We were already using jasmine but where overriding those
methods with jest versions which was not needed.
The previous karma setup also used a single entrypoint which meant that
not all integration tests were running because all files were not
imported in integrations/index.ts.
This also eliminates 79 dev dependencies.
Switch to using fetch for browser and `node-fetch` for node for the faucet calls. This reduces the webpack bundle by 3.2% or 16.5kb gzipped.
The fundWallet code has been refactored to be much more straight forward due to not having to do such low level operations.
This improves the frontend setup process by no longer requiring several polyfills such as `url`, `stream-http`, and `https-browserify`.
Bump https-proxy-agent to v7 and a dev dependency. This makes
configuring bundlers easier to configure and removes a direct
dependency of `https-proxy-agent`.
BREAKING CHANGE: Configuring a proxy is done by specifying the
`agent` parameter on the ConnectionOptions config. This can use be
created by libraries such as `https-proxy-agent` or any that
implements `http.Agent`.
Reduces the bundle size by 8% (41kb)
BigInteger is now well supported so the library is no longer needed.
BigNumber was already being used by xrpl and they had almost identical
interfaces as they are both based on Java.
This will reduce the bundle size by ~23%(117kb).
Only 4 methods were used `flatten`, `flatMap`, `omitBy`, and `groupBy`.
`omitBy and `groupBy` were recreated while the es2019 implementations of
`flatten` and `flatMap` are used.
`lodash` is still used in the tests which is fine because it makes the
tests cleaner.
Closes#2118
* add XChainCreateBridge integration test
* add XChainCreateClaimID integration test
* add XChainCommit integration test
* add XChainAccountCreateCommit integration test
* simplify tests
* add XChainModifyBridge integration test
* add XChainAddAccountCreateAttestation integration test
* add XChainAddClaimAttestation integration test
* improve SignerListSet integration test
* rename variable to match
* add XChainClaim integration test
* clean up
* add IOU attestation test
* fix integration tests issues
* minor refactors
* fix bug
* [WIP] switch to one bridge for all integration tests
* clean up
* fix tests
* fix + clean up tests
The `xrpl` package had a less than helpful docs when viewed on the npm
website. The fix is a workaround that copies the root `README` over
to `packages/xrpl/README.md` during the `prepare` lifecycle phase.
Fields that were encoded as STAccounts were turning '' into rrrrrrrrrrrrrrrrrrrrrhoLvTp the ACCOUNT_ZERO account. They will now throw a ValidationError.
Invalid addresses on a transaction now throws a ValidationError when submitting a transaction instead of Error('checksum_invalid').
This change updates some error messages for fields a few fields that aren't accounts, DestinationTag or NFTokenID. They will still be of type ValidationError.
Fixes: #2517 and #2475
---------
Co-authored-by: Elliot Lee <github.public@intelliot.com>
- Add missing `type` param
- Clean up typing of `type` param and the response property
`account_objects` of the `account_objects` request
- Create interfaces `HasPreviousTxnID` and `MissingPreviousTxnID`. This
helps clean up type checking with regard to the presence of
`PreviousTxnID` and `MissingPreviousTxnID`
Co-authored-by: Mayukha Vadari <mvadari@ripple.com>
Co-authored-by: Caleb Kniffen <ckniffen@ripple.com>
* Add pseudo transactions as types returned by `tx` and `ledger`
* Make` LedgerEntryResponse` generic to allow custom ledger entries
* Update UNLModify to extend BaseTransaction
* Create type `PseudoTransaction`
Co-authored-by: Caleb Kniffen <ckniffen@ripple.com>
This PR moves createValidateTests.js to xrpl/tools instead of being in the top-level tools folder, and fixes an isString import (changes it from lodash to the in-package version).
You can now `NFTokenMint` and `NFTokenCreateOffer` transactions with
`Flags` set to a map like other transactions with flags do.
ex. `{ tfSellNFToken: true }`
fix: source-maps find their designate source
We weren't including the `src` folder in the files published too npm.
This caused errors such as the following seen in the sandbox and by
users on discord.
```
WARNING in ./node_modules/xrpl/dist/npm/utils/xrpConversion.js
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from '/sandbox/node_modules/xrpl/src/utils/xrpConversion.ts' file: Error: ENOENT: no such file or directory, open '/sandbox/node_modules/xrpl/src/utils/xrpConversion.ts'
```
- Remove `.gitignore` from individual packages.
- Remove `nyc.config.js` and `.nycrc` since `nyc` is no longer in use
- Remove `.mocharc` and `localIntegrationRunner.html` since `mocha` is
no longer in use.
Expose most of the types in the `xrpl` package. Some renames will only
affect you if you were deep importing these types previously.
Renames of deep importable types:
- `methods/bookOffers`: `TakerAmount` -> `BookOfferCurrency`
- `methods/accountLines`: `Trustline` -> `AccountLinesTrustline`
- `NFTokenMint` needs `NonFungibleTokensV1_1` enabled instead of `NonFungibleTokensV1` .
- `fee_ref` is no longer returned after `XRPFees` amendment is enabled.
- Add `ledger_hash` and `ledger_index` to `account_nfts`,
`nft_buy_offers`, and `nft_sell_offers` requests.
- Add `nft_page` to `ledger_entry` request.
- Create `LookupByLedgerRequest` to clean up `ledger_hash` and
`ledger_index` which are optional on most request objects.
Closes#2135
* Update NFTokenMint test
* Ensure the binary version works as well
* Remove meta being undefined in txResponse
* Remove error test
* Re-add test, error, and lint
* Add meta to test, and add string to allowed type
* Re-add meta being undefined with proper docs
Added network id to the base transaction
Added network id to the server_info response
Added network id to the binary codec
Added network id to client and modify on client.connect()
Added network id to autofill when rippled_version is 1.11.0 or later or network is hooks testnet
Co-authored-by: Phu Pham <ppham@ripple.com>
Co-authored-by: pdp2121 <71317875+pdp2121@users.noreply.github.com>
Co-authored-by: Jackson Mills <aim4math@gmail.com>
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
* fix test:integration command to run tests directly under ./test/integration
* refactor jest setup to have separate config files for integration and unit tests
* update isSigned null check to use &&
* update isSigned to handle multi-signed transactions
* add unit test for multi-signed transaction
---------
Co-authored-by: Elliot Lee <github.public@intelliot.com>
* remove tx serialization check
* clean up
* update changelog
* bring back some of the logic to check txs
* move memo logic to `validate`
* move other checks to `validate`
* fix tests
* update cspell
* add destination_account field to PathOption(path_find method)
* fix field name
* Fix grammar in comment
* Fix sentence with missing end
* Add HISTORY.md
---------
Co-authored-by: Jackson Mills <jmills@ripple.com>
`lsfDisallowIncomingNFTOffer` to `lsfDisallowIncomingNFTokenOffer`
`asfDisallowIncomingNFTOffer` to `asfDisallowIncomingNFTokenOffer`
Related to XRPLF/rippled#4442
* fix serialize/deserialize verficiation bug in Wallet.sign() when signing a non-XRP Payment transaction with an amount that contains trailing insignificant zeros
This works the same as before for Array inputs, but it should now also
work correctly with a wider range of Iterable or ArrayLike input types.
In particular, this makes it work with typed arrays such as Uint8Array,
which previously produced invalid output due to the hex numerals being
coerced back to the element type before the call to `join('')`.
* Add parseNFTokenID and tests
* Lint
* Move parseNFTokenID to utils
* Lint
* Move the NFTokenID into models
* Move NFTokenID type out of models
* Lint
* Remove extra type and lint
* TrustSet interface amount type changed
Before this edit, if you worked with TrustSet transaction response and you wanted to get LimitAmount.currency, LimitAmount.issuer, and LimitAmount.value, you would get a type error that those properties do not exist on the type string of LimitAmount. This very little edit changes that and now it should work properly.
* Update HISTORY.md
* various typing fixes for NFT support that were originally missed
* add optional faucet URL to fundWallet
* run docgen and commit changes
* fixes integration tests
* Update: Add hash and date type to TxSubscription and Tx responses.
The base transaction interface has been updated to include a hash type.
* Every signed transaction has a unique "hash" that identifies it.
* The transaction hash can be used as a "proof of payment" to verify the final status.
Co-authored-by: interc0der <86900618+interc0der@users.noreply.github.com>
Co-authored-by: Elliot Lee <github.public@intelliot.com>
* rename: branch develop -> main; master -> old-master
* Update all references to `master` and `develop`
* Update the GitHub pages docs
Co-authored-by: Jackson Mills <jmills@ripple.com>, Elliot Lee <intelliot@ripple.com>
3D Globe written in three.js connected to a Node.js websocket server that is listening to exchanges and the XRPL. The visualization aims to show trading, ODL, and liquidity at exchanges, intra-exchange volume, and flows.
## Wallets and wallet tools
- **[XUMM](https://xumm.app/)**
Users can use the xumm application to track their accounts, balances and transactions. The true power of xumm is the platform available for developers.
- **[ILP-enabled power switch](https://xrpcommunity.blog/raspberry-pi-interledger-xp-powerswitch-howto/)** ([video](https://www.youtube.com/watch?v=c-eS0HQUuJg)) (uses [`moneyd-uplink-xrp`](https://github.com/interledgerjs/moneyd-uplink-xrp))
For about $30 in parts (Raspberry Pi, 3.3V Relay board and a few wires) you can build your own power switch that will switch on if a streaming ILP payment comes in. When the payment stream stops, the power turns off.
- You should open a PR against `main` and ensure that all CI passes.
- Your changes should have [unit](#unit-tests) and/or [integration tests](#integration-tests).
- Your changes should [pass the linter](#run-the-linter).
- You should get a full code review from two of the maintainers.
- Then you can merge your changes. (Which will then be included in the next release)
## Set up your dev environment
### Requirements
We use Node v14 for development - that is the version that our linters require.
We use Node v18 for development - that is the version that our linters require.
You must also use `npm` v7. You can check your `npm` version with:
```bash
@@ -38,7 +46,8 @@ npm run lint
```
## Running Tests
For integration and browser tests, we use a `rippled` node in standalone mode to test xrpl.js code against. To set this up, you can either run `rippled` locally, or set up the Docker container `natenichols/rippled-standalone:latest` for this purpose. The latter will require you to [install Docker](https://docs.docker.com/get-docker/).
For integration and browser tests, we use a `xahaud` node in standalone mode to test xahau.js code against. To set this up, you can either configure and run `xahaud` locally, or set up the Docker container `xahauci/xahaud` by [following these instructions](#integration-tests). The latter will require you to [install Docker](https://docs.docker.com/get-docker/).
### Unit Tests
@@ -50,14 +59,24 @@ npm test
### Integration Tests
From the top-level xahau.js folder (one level above `packages`), run the following commands:
```bash
npm install
# sets up the rippled standalone Docker container - you can skip this step if you already have it set up
docker run -p 6006:6006 -it natenichols/rippled-standalone:latest
# sets up the xahaud standalone Docker container - you can skip this step if you already have it set up
docker run -p 6006:6006 --interactive -t --volume $PWD/.ci-config:/opt/xahau/etc/ --platform linux/amd64 xahauci/xahaud:2025.2.6 /opt/xahau/bin/xahaud -a --conf /opt/xahau/etc/xahaud.cfg
npm run build
npm run test:integration
```
Breaking down the command:
*`docker run -p 6006:6006` starts a Docker container with an open port for admin WebSocket requests.
*`--interactive` allows you to interact with the container.
*`-t` starts a terminal in the container for you to send commands to.
*`--volume $PWD/.ci-config:/config/` identifies the `xahaud.cfg` and `validators.txt` to import. It must be an absolute path, so we use `$PWD` instead of `./`.
*`xahauci/xahaud` is an image that is regularly updated with the latest `xahaud` releases
*`/opt/xahau/bin/xahaud -a --conf /opt/xahau/etc/xahaud.cfg` starts `xahaud` in standalone mode
### Browser Tests
There are two ways to run browser tests.
@@ -66,30 +85,82 @@ One is in the browser - run `npm run build:browserTests` and open `test/localInt
The other is in the command line (this is what we use for CI) -
This should be run from the `xahau.js` top level folder (one above the `packages` folder).
```bash
npm run build
# sets up the rippled standalone Docker container - you can skip this step if you already have it set up
docker run -p 6006:6006 -it natenichols/rippled-standalone:latest
# sets up the xahaud standalone Docker container - you can skip this step if you already have it set up
docker run -p 6006:6006 --interactive -t --volume $PWD/.ci-config:/opt/xahau/etc/ --platform linux/amd64 xahauci/xahaud:2025.2.6 /opt/xahau/bin/xahaud -a --conf /opt/xahau/etc/xahaud.cfg
npm run test:browser
```
## High Level Architecture
This is a monorepo, which means that there are multiple packages in a single GitHub repository using [Lerna](https://lerna.js.org/).
The 4 packages currently here are:
1. xahau.js - The client library for interacting with the ledger.
2. xahau-binary-codec - A library for serializing and deserializing transactions for the ledger.
3. xahau-keypairs - A library for generating and using cryptographic keypairs.
4. xahau-address-codec - A library for encoding and decoding Xahau Ledger addresses and seeds.
5. isomorphic - A collection of isomorphic implementations of crypto and utility functions.
6. secret-numbers - Generate XRPL Accounts with a number-based secret: 8 chunks of 6 digits.
Each package has it's own README which dives deeper into what it's main purpose is, and the core functionality it offers.
They also run tests independently as they were originally in separate repositories.
These are managed in a monorepo because often a change in a lower-level library will also require a change in xahau.js, and so it makes sense to be able to allow for modifications of all packages at once without coordinating versions across multiple repositories.
Let's dive a bit into how xahau.js is structured!
### The File Structure
Within the xrpl package, each folder has a specific purpose:
**Client** - This contains logic for handling the websocket connection to xahaud servers.
**Models** - These types model LedgerObjects, Requests/Methods, and Transactions in order to give type hints and nice errors for users.
**Sugar** - This is where handy helper functions end up, like `submit`, `autofill`, and `getXAHBalance` amongst others.
**Utils** - These are shared functions which are useful for conversions, or internal implementation details within the library.
**Wallet** - This logic handles managing keys, addresses, and signing within xahau.js
### Writing Tests for xahau.js
For every file in `src`, we try to have a corresponding file in `test` with unit tests.
The goal is to maintain above 80% code coverage, and generally any new feature or bug fix should be accompanied by unit tests, and integration tests if applicable.
For an example of a unit test, check out the [autofill tests here](./packages/xahau/test/client/autofill.ts).
If your code connects to the ledger (ex. Adding a new transaction type) it's handy to write integration tests to ensure that you can successfully interact with the ledger. Integration tests are generally run against a docker instance of xahaud which contains the latest updates. Since standalone mode allows us to manually close ledgers, this allows us to run integration tests at a much faster rate than if we had to wait 4-5 seconds per transaction for the ledger to validate the transaction. [See above](#running-tests) for how to start up the docker container to run integration tests.
All integration tests should be written in the `test/integration` folder, with new `Requests` and `Transactions` tests being in their respective folders.
For an example of how to write an integration test for `xahau.js`, you can look at the [Payment integration test](./packages/xahau/test/integration/transactions/payment.ts).
## Generate reference docs
You can see the complete reference documentation at [`xrpl.js` docs](js.xrpl.org). You can also generate them locally using `typedoc`:
You can see the complete reference documentation at [`xahau.js` docs](https://js.xrpl.org). You can also generate them locally using `typedoc`:
```bash
npm run docgen
```
This updates `docs/` at the top level, where GitHub Pages looks for the docs.
## Update `definitions.json`
Use [this repo](https://github.com/RichardAH/xrpl-codec-gen) to generate a new `definitions.json` file from the xahaud source code. Instructions are available in that README.
## Adding and removing packages
`xrpl.js` uses `lerna` and `npm`'s workspaces features to manage a monorepo.
`xahau.js` uses `lerna` and `npm`'s workspaces features to manage a monorepo.
Adding and removing packages requires a slightly different process than normal
as a result.
### Adding or removing development dependencies
`xrpl.js` strives to use the same development dependencies in all packages.
`xahau.js` strives to use the same development dependencies in all packages.
You may add and remove dev dependencies like normal:
- You can look up the name by searching for the hash on https://xrpl.org/known-amendments.html
4. Push your changes
### Release
Note: The same updated config can be used to update xahau-py's CI as well.
## Updating `definitions.json`
This should almost always be done using the [`xrpl-codec-gen`](https://github.com/RichardAH/xrpl-codec-gen) script - if the output needs manual intervention afterwards, consider updating the script instead.
1. Clone / pull the latest changes from [xahaud](https://github.com/XRPLF/xahaud) - Specifically the `develop` branch is usually the right one.
2. Clone / pull the latest changes from [`xrpl-codec-gen`](https://github.com/RichardAH/xrpl-codec-gen)
3. From the `xrpl-codec-gen` tool, follow the steps in the `README.md` to generate a new `definitions.json` file.
4. Replace the `definitions.json` file in the `xahau-binary-codec` with the newly generated file.
5. Verify that the changes make sense by inspection before submitting, as there may be updates required for the `xrpl-codec-gen` tool depending on the latest amendments we're updating to match.
## Release process + checklist
## PR process
- [ ] Your changes should be on a branch.
- [ ] Your changes should have unit tests.
- [ ] Lint the code with `npm lint`
- [ ] Build your code with `npm build`
- [ ] Run the unit tests with `npm test`
- [ ] Get a full code review.
- [ ] Merge your branch into `main` and push to github.
- [ ] Ensure that all tests passed on the last CI that ran on `main`.
## Release
1. Checkout `main` (or your beta branch) and `git pull`.
1. Create a new branch (`git checkout -b <BRANCH_NAME>`) to capture updates that take place during this process.
1. Update `HISTORY.md` to reflect release changes.
- [ ] Update the version number and release date, and ensure it lists the changes since the previous release.
1. Run `npm run docgen` if the docs were modified in this release to update them (skip this step for a beta).
1. Run `npm run build` to triple check the build still works
1. Run `npx lerna version --no-git-tag-version` - This bumps the package versions.
- For each changed package, pick what the new version should be. Lerna will bump the versions, commit version bumps to `main`, and create a new git tag for each published package.
- If you do NOT want to update the package number, choose "Custom Version" and set the version to be the same as the existing version. Lerna will not publish any changes in this case.
- If publishing a beta, make sure that the versions are all of the form `a.b.c-beta.d`, where `a`, `b`, and `c` are identical to the last normal release except for one, which has been incremented by 1.
1. Run `npm i` to update the package-lock with the updated versions.
1. Create a new PR from this branch into `main` and merge it (you can directly merge into the beta branch for a beta).
1. Checkout `main` and `git pull` (you can skip this step for a beta since you already have the latest version of the beta branch).
1. Actually publish the packages with one of the following:
- Stable release: Run `npx lerna publish from-package --yes`
Notice this allows developers to install the package with `npm add xahau@beta`
1. If requested, enter your [npmjs.com](https://npmjs.com) OTP (one-time password) to complete publication.
NOW YOU HAVE PUBLISHED! But you're not done; we have to notify people!
1. Run `git tag <tagname> -m <tagname>`, where `<tagname>` is the new package and version (e.g. `xahau@2.1.1`), for each version released.
1. Run `git push --follow-tags`, to push the tags to Github.
1. On GitHub, click the "Releases" link on the right-hand side of the page.
1. Repeat for each release:
1. Click "Draft a new release"
1. Click "Choose a tag", and choose a tag that you just created.
1. Edit the name of the release to match the tag (IE \<package\>@\<version\>) and edit the description as you see fit.
1. Send an email to [xahau-announce](https://groups.google.com/g/xahau-announce).
1. Lastly, send a similar message to the Xahau Discord in the [`javascript` channel](https://discord.com/channels/1085202760548499486/1085203623111295068). The message should include:
1. The version changes for xahau libraries
1. A link to the more detailed changes
1. Highlights of important changes
1. Ensure that all tests passed on the last CI that ran on `develop`.
2. Open a PR to update the docs if docs were modified.
3. Create a branch off `develop` that ensures that `HISTORY.md` is updated appropriately for each package.
* Use `shasum -a 256 build/*` to get the SHA-256 checksums. Add these to `HISTORY.md` as well.
4. Merge this branch into `develop`.
5. If this is not a beta release: Merge `develop` into `master` (`--ff-only`) and push to github. This is important because we have docs telling developers to use master to get the latest release.
6. Create a new Github release/tag off of this branch.
7. Run `npm publish --dry-run` and make sure everything looks good.
8. Publish the release to `npm`.
* If this is a beta release, run `npm publish --tag beta`. This allows someone else to install this version of the package with `npm install xrpl@beta`.
* If this is a stable release, run `npm publish`.
* This will require entering `npm` login info.
9. Send an email to [xrpl-announce](https://groups.google.com/g/xrpl-announce).
## Mailing Lists
We have a low-traffic mailing list for announcements of new `xrpl.js` releases. (About 1 email every couple of weeks)
+ [Subscribe to xrpl-announce](https://groups.google.com/g/xrpl-announce)
We have a low-traffic mailing list for announcements of new `xahau.js` releases. (About 1 email every couple of weeks)
If you're using the XRP Ledger in production, you should run a [rippled server](https://github.com/ripple/rippled) and subscribe to the ripple-server mailing list as well.
- [Subscribe to xahau-announce](https://groups.google.com/g/xahau-announce)
+ [Subscribe to ripple-server](https://groups.google.com/g/ripple-server)
If you're using the Xahau Ledger in production, you should run a [xahaud server](https://github.com/xahau/xahaud) and subscribe to the xahau-server mailing list as well.
- [Subscribe to xahau-server](https://groups.google.com/g/xahau-server)
Please see the individual HISTORY.md documents in each package for changes.
Please see the individual HISTORY.md and XAHAU_HISTORY.md documents in each package for changes:
* [Release History for **xahau.js**](packages/xrpl/HISTORY.md)
* The **xahau** package is a TypeScript/JavaScript library for interacting with the [Xahau Ledger](https://docs.xahau.network/).
* [Release History for **xahau-address-codec**](packages/xahau-address-codec/HISTORY.md)
* The **xahau-address-codec** package provides functions for encoding and decoding Xahau Ledger addresses and seeds.
* [Release History for **xahau-binary-codec**](packages/xahau-binary-codec/HISTORY.md)
* The **xahau-binary-codec** package provides functions to encode to, and decode from, the Xahau binary serialization format.
* [Release History for **xahau-keypairs**](packages/xahau-keypairs/HISTORY.md)
* The **xahau-keypairs** package implements Xahau cryptographic keypair and wallet generation, with support for rfc6979 and EdDSA deterministic signatures.
This is the recommended library for integrating a JavaScript/TypeScript app with the XRP Ledger, especially if you intend to use advanced functionality such as IOUs, payment paths, the decentralized exchange, account settings, payment channels, escrows, multi-signing, and more.
This is the recommended library for integrating a JavaScript/TypeScript app with the Xahau Ledger, especially if you intend to use advanced functionality such as IOUs, payment paths, the decentralized exchange, account settings, payment channels, escrows, multi-signing, and more.
See the full reference documentation for all classes, methods, and utilities.
## [➡️ Applications and Projects](https://github.com/XRPLF/xrpl.js/blob/master/APPLICATIONS.md)
## Features
What is `xrpl.js` used for? The applications on the list linked above use `xrpl.js`. Open a PR to add your app or project to the list!
1. Managing keys & creating test credentials ([`Wallet`](https://js.xahau.org/classes/Wallet.html) && [`Client.fundWallet()`](https://js.xahau.org/classes/Client.html#fundWallet))
2. Submitting transactions to the Xahau Ledger ([`Client.submit(...)`](https://js.xahau.org/classes/Client.html#submit) & [transaction types](https://xahau.org/transaction-types.html))
3. Sending requests to observe the ledger ([`Client.request(...)`](https://js.xahau.org/classes/Client.html#request) using [public API methods](https://xahau.org/public-api-methods.html))
4. Subscribing to changes in the ledger ([Ex. ledger, transactions, & more...](https://xahau.org/subscribe.html))
5. Parsing ledger data into more convenient formats ([`xrpToDrops`](https://js.xahau.org/functions/xrpToDrops.html) and [`rippleTimeToISOTime`](https://js.xahau.org/functions/rippleTimeToISOTime.html))
### Features
All of which works in Node.js (tested for v18+) & web browsers (tested for Chrome). -->
+ Works in Node.js and in web browsers
+ Helpers for creating requests and parsing responses for the [XRP Ledger APIs](https://xrpl.org/rippled-api.html)
+ Listen to events on the XRP Ledger (transactions, ledger, validations, etc.)
+ Sign and submit transactions to the XRP Ledger
+ Type definitions for TypeScript
# Quickstart
### Requirements
+ **[Node.js v14](https://nodejs.org/)** is recommended. We also support v12 and v16. Other versions may work but are not frequently tested.
+ **[Node.js v18](https://nodejs.org/)** is recommended. We also support v20. Other versions may work but are not frequently tested.
## Getting Started
### Installing xahau.js
In an existing project (with `package.json`), install `xrpl.js`:
In an existing project (with package.json), install xahau.js with:
For more examples, see the [documentation](#documentation).
### Using xrpl.js with React Native
If you want to use `xrpl.js` with React Native you will need to install shims for core NodeJS modules. To help with this you can use a module like [rn-nodeify](https://github.com/tradle/rn-nodeify).
1. Install dependencies (you can use `yarn` as well):
```shell
npm install react-native-crypto
npm install xrpl
# install peer deps
npm install react-native-randombytes
# install latest rn-nodeify
npm install rn-nodeify@latest --dev
```
2. After that, run the following command:
```shell
# install node core shims and recursively hack package.json files
# in ./node_modules to add/update the "browser"/"react-native" field with relevant mappings
./node_modules/.bin/rn-nodeify --hack --install
```
3. Enable `crypto`:
`rn-nodeify` will create a `shim.js` file in the project root directory.
Open it and uncomment the line that requires the crypto module:
```javascript
// If using the crypto shim, uncomment the following line to ensure
// crypto is loaded first, so it can populate global.crypto
require('crypto')
```
4. Import `shim` in your project (it must be the first line):
```javascript
import './shim'
...
```
### Using xrpl.js with Deno
Until official support for [Deno](https://deno.land) is added, you can use the following work-around to use `xrpl.js` with Deno:
```javascript
import xrpl from 'https://dev.jspm.io/npm:xrpl';
(async () => {
const api = new (xrpl as any).Client('wss://s.altnet.rippletest.net:51233');
As you develop with xahau.js, there's two sites you'll use extensively:
1. [docs.xahau.network](https://docs.xahau.network/technical/protocol-reference) is the primary source for:
- How the ledger works ([See Concepts](https://docs.xahau.network/))
- What kinds of transactions there are ([Transaction Types](https://docs.xahau.network/technical/protocol-reference/transactions/transaction-types))
- Requests you can send ([Public API Methods](https://docs.xahau.network/features/http-websocket-apis))
### Mailing Lists
We have a low-traffic mailing list for announcements of new `xrpl.js` releases. (About 1 email per week)
If you want to hear when we release new versions of xahau.js, you can join our low-traffic mailing list (About 1 email per week):
+ [Subscribe to xrpl-announce](https://groups.google.com/g/xrpl-announce)
- [Subscribe to xahau-announce](https://groups.google.com/g/xahau-announce)
If you're using the XRP Ledger in production, you should run a [rippled server](https://github.com/ripple/rippled) and subscribe to the ripple-server mailing list as well.
If you're using the Xahau Ledger in production, you should run a [xahaud server](https://github.com/Xahau/xahaud) and subscribe to the xahau-server mailing list as well.
+ [Subscribe to ripple-server](https://groups.google.com/g/ripple-server)
- [Subscribe to xahau-server](https://groups.google.com/g/xahau-server)
## More Information
+ [xrpl-announce mailing list](https://groups.google.com/g/xrpl-announce) - subscribe for release announcements
+ [xrpl.js API Reference](https://js.xrpl.org)
+ [XRP Ledger Dev Portal](https://xrpl.org)
You are also welcome to create an [issue](https://github.com/Xahau/xahau.js/issues) here and we'll do our best to respond within 3 days.
This table shows which versions of xrpl.js are currently supported with security updates:
| Version | Supported |
| ------- | ---------------------- |
| 2.x | :white_check_mark: Yes |
| 1.x | :white_check_mark: Yes |
| 0.x | :x: No |
## Responsible disclosure security policy
The responsible disclosure of vulnerabilities helps to protect users of the project. Vulnerabilities are first triaged in a private manner, and only publicly disclosed after a reasonable time period that allows patching the vulnerability and provides an upgrade path for users.
When contacting us directly via email, we will do our best to respond in a reasonable time to resolve the issue. Do not disclose the vulnerability until it has been patched and users have been given time to upgrade.
We kindly ask you to refrain from malicious acts that put our users, the project, or any of the project’s team members at risk.
## Reporting a security issue
Security is a top priority. But no matter how much effort we put into security, there can still be vulnerabilities present.
If you discover a security vulnerability, please use the following means of communications to report it to us:
These are the [types](https://xrpl.org/serialization.html#type-list) associated with a given Serialization Field. Each type has an arbitrary [type_code](https://xrpl.org/serialization.html#type-codes), with lower codes sorting first.
## Ledger Entry Types
Each ledger's state tree contain [ledger objects](https://xrpl.org/ledger-object-types.html), which represent all settings, balances, and relationships in the shared ledger.
## Fields
These are Serialization Fields (`sf`) [defined in rippled's SField.cpp](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/SField.cpp). Fields with undefined values are omitted before encoding.
### Key
The key is the string defined in the rippled source code, such as "LedgerEntry", "Transaction", etc.
### nth
`nth` is the sort code, meaning "nth of type." It is is combined with the type code in order to construct the Field ID of this field. The Field ID is only used for sorting the fields. Since there are multiple fields with the same data type, the `nth` is used to deterministically order each field among other fields of the same data type.
Each field has a Field ID, which is used to sort fields that have the same type as one another with lower codes sorting first.
- [Constructing the `SField` field codes](https://github.com/ripple/rippled/blob/eaff9a0e6aec0ad077f118501791c7684debcfd5/src/ripple/protocol/SField.h#L95-L98)
For example, the `Account` field has sort code (nth) `1`, so it comes before the `Destination` field which has sort code `3`.
Sort code numbers are reused for fields of different types, but different fields of the same type never have the same sort code. When you combine the type code with the sort code, you get the field's unique _Field ID_.
The unique [Field ID](https://xrpl.org/serialization.html#field-ids) is prefixed before the field in the final serialized blob. The size of the Field ID is one to three bytes depending on the type code and the field codes it combines.
### isVLEncoded
If true, the field is Variable Length encoded and [length-prefixed](https://xrpl.org/serialization.html#length-prefixing). The variable-length encoded fields are `STI_VL`/`Blob`, `STI_ACCOUNT`/`AccountID`, and `STI_VECTOR256`/`Vector256`.
### isSerialized
Fields are serialized if they are not [one of these](https://github.com/ripple/rippled/blob/eaff9a0e6aec0ad077f118501791c7684debcfd5/src/ripple/protocol/impl/SField.cpp#L71-L78) or if they are not an SField.
True unless the field is [specified with `SField::notSigning`](https://github.com/ripple/rippled/blob/eaff9a0e6aec0ad077f118501791c7684debcfd5/src/ripple/protocol/impl/SField.cpp#L198).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.