mirror of
https://github.com/logos-messaging/docs.waku.org.git
synced 2026-01-04 05:43:07 +00:00
Upgrade docusaurus and preset version (#244)
* feat: upgrade docusaurus and preset version * feat: add node fetch-content.js to build script
This commit is contained in:
Jinho Jang
GitHub
parent
1bebfcb396
commit
1572d6cb30
@ -83,7 +83,7 @@
|
||||
"IPFS",
|
||||
"cheatsheet",
|
||||
"hacken",
|
||||
"statusteam",
|
||||
"statusteam"
|
||||
],
|
||||
"flagWords": [],
|
||||
"ignorePaths": [
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
[](https://docs.waku.org/)
|
||||
|
||||
The Waku Documentation Portal can be accessed at <https://docs.waku.org/> and was built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
|
||||
The Waku Documentation Portal can be accessed at [https://docs.waku.org/](https://docs.waku.org/) and was built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@ -88,8 +88,8 @@ yarn clear
|
||||
|
||||
## CI/CD
|
||||
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/docs.waku.org/) `master` and pushes to `deploy-master` branch, which is hosted at <https://docs.waku.org/>.
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/dev-docs.waku.org/) `develop` and pushes to `deploy-develop` branch, which is hosted at <https://dev-docs.waku.org/>.
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/docs.waku.org/) `master` and pushes to `deploy-master` branch, which is hosted at [https://docs.waku.org/](https://docs.waku.org/).
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/dev-docs.waku.org/) `develop` and pushes to `deploy-develop` branch, which is hosted at [https://dev-docs.waku.org/](https://dev-docs.waku.org/).
|
||||
|
||||
The hosting is done using [Caddy server with Git plugin for handling GitHub webhooks](https://github.com/status-im/infra-misc/blob/master/ansible/roles/caddy-git).
|
||||
|
||||
@ -101,4 +101,3 @@ Information about deployed build can be also found in `/build.json` available on
|
||||
2. Make your changes, push them to the origin, and open a Pull Request against the develop branch.
|
||||
3. After approval, merge the pull request, and verify the changes on the staging server (e.g., https://dev.vac.dev).
|
||||
4. When ready to promote changes to the live website, rebase the master branch on the staging changes: git checkout master; git pull origin master; git rebase origin/develop; git push.
|
||||
|
||||
|
||||
@ -42,7 +42,7 @@ Check out our [Learn section](/learn/waku-network), [YouTube channel](https://ww
|
||||
8. **Social Media Platforms**: Beyond chat messengers, use Waku for decentralised, censorship-resistant social media platforms like news feeds and multimedia sharing.
|
||||
|
||||
:::tip
|
||||
Looking for what to build with Waku? Discover a collection of sample ideas and use cases for inspiration, curated by our community at: https://ideas.waku.org/ and [Awesome Waku](https://github.com/waku-org/awesome-waku/).
|
||||
Looking for what to build with Waku? Discover a collection of sample ideas and use cases for inspiration, curated by our community at: [https://ideas.waku.org/](https://ideas.waku.org/) and [Awesome Waku](https://github.com/waku-org/awesome-waku/).
|
||||
:::
|
||||
|
||||
## Case studies
|
||||
@ -89,5 +89,5 @@ Waku is implemented in multiple SDKs, allowing it to integrate with different la
|
||||
| [@waku/create-app](https://www.npmjs.com/package/@waku/create-app) | Starter kit to bootstrap your next `@waku/sdk` project from various example templates | [Scaffold DApps Using @waku/create-app](/guides/js-waku/use-waku-create-app) |
|
||||
|
||||
:::tip
|
||||
Explore some example apps built using Waku at https://examples.waku.org/ and view a list of projects and workshops from previous hackathons at [Awesome Waku](https://github.com/waku-org/awesome-waku/).
|
||||
Explore some example apps built using Waku at [https://examples.waku.org/](https://examples.waku.org/) and view a list of projects and workshops from previous hackathons at [Awesome Waku](https://github.com/waku-org/awesome-waku/).
|
||||
:::
|
||||
|
||||
@ -3,6 +3,9 @@ title: Bootstrap Nodes and Discover Peers
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This guide provides detailed steps to bootstrap your your node using [Static Peers](/learn/concepts/static-peers) and discover peers in the Waku Network using [DNS Discovery](/learn/concepts/dns-discovery).
|
||||
|
||||
:::info
|
||||
@ -61,7 +64,6 @@ const peers = [
|
||||
"/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ",
|
||||
];
|
||||
|
||||
|
||||
const node = await createLightNode();
|
||||
|
||||
// In case nodes are using IP address and / or `ws` protocol - additional configuration is needed:
|
||||
@ -73,7 +75,7 @@ const node = await createLightNode({
|
||||
});
|
||||
*/
|
||||
|
||||
const promises = peers.map(multiaddr => node.dial(multiaddr));
|
||||
const promises = peers.map((multiaddr) => node.dial(multiaddr));
|
||||
|
||||
await Promise.all(promises);
|
||||
```
|
||||
@ -122,12 +124,7 @@ const NODE_REQUIREMENTS = {
|
||||
// Bootstrap node using DNS Discovery
|
||||
const node = await createLightNode({
|
||||
libp2p: {
|
||||
peerDiscovery: [
|
||||
wakuDnsDiscovery(
|
||||
[enrTree],
|
||||
NODE_REQUIREMENTS,
|
||||
),
|
||||
],
|
||||
peerDiscovery: [wakuDnsDiscovery([enrTree], NODE_REQUIREMENTS)],
|
||||
},
|
||||
});
|
||||
```
|
||||
@ -141,10 +138,7 @@ import { enrTree } from "@waku/dns-discovery";
|
||||
const node = await createLightNode({
|
||||
libp2p: {
|
||||
peerDiscovery: [
|
||||
wakuDnsDiscovery(
|
||||
[enrTree["PROD"], enrTree["TEST"]],
|
||||
NODE_REQUIREMENTS,
|
||||
),
|
||||
wakuDnsDiscovery([enrTree["PROD"], enrTree["TEST"]], NODE_REQUIREMENTS),
|
||||
],
|
||||
},
|
||||
});
|
||||
@ -176,12 +170,7 @@ const NODE_REQUIREMENTS = {
|
||||
const node = await createLightNode({
|
||||
libp2p: {
|
||||
bootstrapPeers: peers,
|
||||
peerDiscovery: [
|
||||
wakuDnsDiscovery(
|
||||
[enrTree["PROD"]],
|
||||
NODE_REQUIREMENTS,
|
||||
),
|
||||
],
|
||||
peerDiscovery: [wakuDnsDiscovery([enrTree["PROD"]], NODE_REQUIREMENTS)],
|
||||
},
|
||||
});
|
||||
```
|
||||
@ -31,4 +31,4 @@ Before using `@waku/sdk` in a NodeJS environment, take into account these limita
|
||||
|
||||
## Future developments
|
||||
|
||||
There are plans to release a NodeJS package based on [nwaku](/guides/nwaku/run-node) to streamline the process of using Waku Network features in NodeJS applications. You can track the progress and updates here: <https://github.com/waku-org/nwaku/issues/1332>.
|
||||
There are plans to release a NodeJS package based on [nwaku](/guides/nwaku/run-node) to streamline the process of using Waku Network features in NodeJS applications. You can track the progress and updates here: [https://github.com/waku-org/nwaku/issues/1332](https://github.com/waku-org/nwaku/issues/1332).
|
||||
|
||||
@ -49,4 +49,4 @@ We welcome and appreciate the contributions of templates for the `@waku/create-a
|
||||
4. Finally, submit a pull request to the [js-waku-examples](https://github.com/waku-org/js-waku-examples) repository.
|
||||
5. Our team will carefully review and merge your submission upon approval.
|
||||
|
||||
Waku also provides bounties to encourage community members to contribute to the network and earn rewards. To participate in the bounty program, head to <https://github.com/waku-org/bounties>.
|
||||
Waku also provides bounties to encourage community members to contribute to the network and earn rewards. To participate in the bounty program, head to [https://github.com/waku-org/bounties](https://github.com/waku-org/bounties).
|
||||
|
||||
@ -8,7 +8,7 @@ Here are the available node configuration options, along with their default valu
|
||||
## Application-level config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| ----------------- | --------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
| ----------------- | --------------------------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| `config-file` | | Loads configuration from a TOML file (cmd-line parameters take precedence) |
|
||||
| `protected-shard` | `newSeq[ProtectedShard](0)` | Shards and its public keys to be used for message validation, shard:pubkey. Argument may be repeated |
|
||||
|
||||
@ -22,14 +22,14 @@ Here are the available node configuration options, along with their default valu
|
||||
## General node config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| --------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------- |
|
||||
| --------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `cluster-id` | `0` | Cluster id that the node is running in. Node in a different cluster id is disconnected |
|
||||
| `agent-string` | `nwaku` | Node agent string which is used as identifier in network |
|
||||
| `nodekey` | | P2P node private key as 64-char hex string |
|
||||
| `listen-address` | `defaultListenAddress()` | Listening address for LibP2P (and Discovery v5, if enabled) traffic |
|
||||
| `tcp-port` | `60000` | TCP listening port |
|
||||
| `ports-shift` | `0` | Add a shift to all port numbers |
|
||||
| `nat` | any | Specify method to use for determining public address. Must be one of: any, none, upnp, pmp, extip:<IP\> |
|
||||
| `nat` | any | Specify method to use for determining public address. Must be one of: any, none, upnp, pmp, extip:IP |
|
||||
| `ext-multiaddr` | | External multiaddresses to advertise to the network. Argument may be repeated |
|
||||
| `ext-multiaddr-only` | `false` | Only announce external multiaddresses |
|
||||
| `max-connections` | `50` | Maximum allowed number of libp2p connections |
|
||||
@ -48,7 +48,7 @@ Here are the available node configuration options, along with their default valu
|
||||
## Relay config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| -------------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| -------------------------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `relay` | `true` | Enable relay protocol: true\|false |
|
||||
| `relay-peer-exchange` | `false` | Enable gossipsub peer exchange in relay protocol: true\|false |
|
||||
| `rln-relay` | `false` | Enable spam protection through rln-relay: true\|false |
|
||||
@ -72,7 +72,6 @@ Here are the available node configuration options, along with their default valu
|
||||
| `content-topic` | | Default content topic to subscribe to. Argument may be repeated |
|
||||
| `reliability` | `false` | Enable experimental reliability protocol true\|false |
|
||||
|
||||
|
||||
## Store and message store config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
@ -87,7 +86,7 @@ Here are the available node configuration options, along with their default valu
|
||||
## Store Sync
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| -------------------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| ------------------------- | --------------- | ------------------------------------------------------------------- |
|
||||
| `store-sync` | `false` | Enable/disable waku store sync protocol |
|
||||
| `store-sync-interval` | `300` 5 minutes | Interval between store synchronization attempts |
|
||||
| `store-sync-range` | `3600` 1 hour | Amount of time to sync |
|
||||
@ -106,8 +105,8 @@ Here are the available node configuration options, along with their default valu
|
||||
## Light push config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| --------------- | ------------- | --------------------------------------------------------- |
|
||||
| `lightpush` | `false` | Enable lightpush protocol: true\|false |
|
||||
| --------------- | ------------- | --------------------------------------------------------- | ----- |
|
||||
| `lightpush` | `false` | Enable lightpush protocol: true | false |
|
||||
| `lightpushnode` | | Peer multiaddr to request lightpush of published messages |
|
||||
|
||||
## REST HTTP config
|
||||
@ -133,9 +132,9 @@ Here are the available node configuration options, along with their default valu
|
||||
## DNS discovery config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| --------------------------- | ------------------------ | ---------------------------------------------------------- |
|
||||
| --------------------------- | ------------------------ | ------------------------------------------------------------ |
|
||||
| `dns-discovery` | `false` | Enable discovering nodes via DNS |
|
||||
| `dns-discovery-url` | | URL for DNS node list in format 'enrtree://<key\>@<fqdn\>' |
|
||||
| `dns-discovery-url` | | URL for DNS node list in format `'enrtree://<key\>@<fqdn\>'` |
|
||||
| `dns-discovery-name-server` | `["1.1.1.1", "1.0.0.1"]` | DNS name server IPs to query. Argument may be repeated |
|
||||
| `rendezvous` | `true` | Enable waku rendezvous discovery server |
|
||||
|
||||
@ -171,7 +170,7 @@ Here are the available node configuration options, along with their default valu
|
||||
## Non-relay, request-response protocol DOS protection configuration
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| ---------------------------- | ------------- | ------------------------------------------------------ |
|
||||
| ------------ | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `rate-limit` | | This is a repeatable option. Each can describe a specific rate limit configuration for a particular protocol.<br />Formatted as:`<protocol>:volume/period<time-unit>`<br />- if protocol is not given, settings will be taken as default for un-set protocols. Ex: `80/2s`<br />-Supported protocols are: `lightpush`\|`filter`\|`px`\|`store`\|`storev2`\|`storev3`<br />-volume must be an integer value, representing number of requests over the period of time allowed.<br />-period\<time-unit\> must be an integer with defined unit as one of `h`\|`m`\|`s`\|`ms`<br />- `storev2` and `storev3` takes precedence over `store` which can easy set both store protocols at once.<br />- In case of multiple set of the same protocol limit, last one will take place.<br />- if config is not set, - which is the default - means unlimited requests are allowed.<br />-filter has a bit different approach. It has a default setting applied if not overridden. Rate limit setting for filter will be applied per subscriber-peers, not globally - it must be considered when changing the setting.<br /><br />Examples:<br />`--rate-limit="100/1s"` - default for all protocols if not set otherwise.<br />`--rate-limit="lightpush:0/0s"` - lightpush protocol will not be rate-limited.<br />`--rate-limit="store:130/1500ms"` - both store-v3 and store-v2 will apply 130 request per each 1500ms separately.<br />`--rate-limit="px:10/1h"` PeerExchange will serve only 10 requests every hour.<br />`--rate-limit="filter:8/5m"` - will allow 8 subs/unsubs/ping requests for each subscriber within every 5 min. |
|
||||
|
||||
:::tip
|
||||
|
||||
@ -81,7 +81,7 @@ docker-compose logs -f nwaku
|
||||
|
||||
## Monitor the node
|
||||
|
||||
Visit <http://localhost:3000/d/yns_4vFVk/nwaku-monitoring> to view your node metrics in real time.
|
||||
Visit [http://localhost:3000/d/yns_4vFVk/nwaku-monitoring](http://localhost:3000/d/yns_4vFVk/nwaku-monitoring) to view your node metrics in real time.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -9,14 +9,14 @@ The following features are currently experimental and under research and initial
|
||||
|
||||
We aim to enable an incentivised spam protection technique to enhance `Relay` by using [Rate Limit Nullifiers (RLN)](https://rfc.vac.dev/vac/32/rln-v1/). In this advanced method, peers are limited to a certain messaging rate per epoch, and an immediate financial penalty is enforced for spammers who break this rate. You can find more details in the [RLN Relay blog post](https://vac.dev/rln-relay).
|
||||
|
||||
We have prepared a PoC implementation of this method in JS: <https://examples.waku.org/rln-js/>
|
||||
We have prepared a PoC implementation of this method in JS: [https://examples.waku.org/rln-js/](https://examples.waku.org/rln-js/)
|
||||
|
||||
## Prevention of denial of service (DoS) and node incentivisation
|
||||
|
||||
Denial of service signifies the case where an adversarial peer exhausts another node's service capacity (e.g., by making a large number of requests) and makes it unavailable to the rest of the system. RnD on DoS attack mitigation can be tracked from here: <https://github.com/vacp2p/research/issues/148>.
|
||||
Denial of service signifies the case where an adversarial peer exhausts another node's service capacity (e.g., by making a large number of requests) and makes it unavailable to the rest of the system. RnD on DoS attack mitigation can be tracked from here: [https://github.com/vacp2p/research/issues/148](https://github.com/vacp2p/research/issues/148).
|
||||
|
||||
In a nutshell, peers have to pay for the service they obtain from each other. In addition to incentivising the service provider, accounting also makes DoS attacks costly for malicious peers. The accounting model can be used in `Store` and `Filter` to protect against DoS attacks.
|
||||
|
||||
Additionally, along with RLN, this gives node operators who provide a useful service to the network an incentive to perform that service. Read more here: <https://vac.dev/building-privacy-protecting-infrastructure>
|
||||
Additionally, along with RLN, this gives node operators who provide a useful service to the network an incentive to perform that service. Read more here: [https://vac.dev/building-privacy-protecting-infrastructure](https://vac.dev/building-privacy-protecting-infrastructure)
|
||||
|
||||
You can also read more about the ongoing challenges the Waku team is working on here: <https://github.com/waku-org/research>
|
||||
You can also read more about the ongoing challenges the Waku team is working on here: [https://github.com/waku-org/research](https://github.com/waku-org/research)
|
||||
|
||||
@ -22,7 +22,7 @@ Anonymity means an adversary cannot connect an actor to their actions or data. T
|
||||
|
||||
The spam protection feature in `Relay` ensures that no adversary can flood the system with many messages, intentionally or not, regardless of the content's validity or usefulness. This protection is achieved through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) of `GossipSub v1.1`. Peers assign scores to their connections based on their behaviour and remove peers with low scores.
|
||||
|
||||
Ongoing research is being conducted, including developing [Rate Limit Nullifiers (RLN)](/learn/concepts/protocols#rln-relay), which can be explored further at: <https://github.com/vacp2p/research/issues/148>.
|
||||
Ongoing research is being conducted, including developing [Rate Limit Nullifiers (RLN)](/learn/concepts/protocols#rln-relay), which can be explored further at: [https://github.com/vacp2p/research/issues/148](https://github.com/vacp2p/research/issues/148).
|
||||
|
||||
## [Data confidentiality, integrity, and authenticity](https://rfc.vac.dev/waku/standards/core/10/waku2/#data-confidentiality-integrity-and-authenticity)
|
||||
|
||||
|
||||
@ -5,12 +5,14 @@ title: RLN Key Benchmarks
|
||||
## Introduction
|
||||
|
||||
Since RLN has been chosen as the spamming protection mechanism for waku, we must understand the practical implications of using it. This issue explains the main differences between `relay` and `rln-relay` and gives some benchmarks after running simulations using `waku-simulator`, in a network with the following characteristics:
|
||||
|
||||
- 100 nwaku nodes, each one with a valid rln membership and publishing a message every 10 seconds to a common topic.
|
||||
- rln contract deployed in Ethereum Sepolia
|
||||
- 10.000 memberships registered in the contract
|
||||
- pure relay (store and light protocols disabled)
|
||||
|
||||
The main deltas `rln` vs `rln-relay` are:
|
||||
|
||||
- New `proof ` field in `WakuMessage` containing 384 extra bytes. This field must be generated and attached to each message.
|
||||
- New validator, that uses `proof` to `Accept` or `Reject` the message. The proof has to be verified.
|
||||
- New dependency on a blockchain, Ethereum, or any EVM chain, to keep track of the members allowed to publish.
|
||||
@ -18,6 +20,7 @@ The main deltas `rln` vs `rln-relay` are:
|
||||
But what are the practical implications of these?
|
||||
|
||||
## TLDR:
|
||||
|
||||
- Proof generation is constant-ish. 0.15 second for each proof
|
||||
- Proof verification is constant-ish, 0.012 seconds. In a network with 10k nodes and D=6 this would add an overhead delay of 0.06 seconds.
|
||||
- Gossipsub scoring drops connections from spammer peers, which acts as the punishment (instead of slashing). Validated in the simulation.
|
||||
@ -48,13 +51,15 @@ In the following simulation, we can see `100` nwaku interconnected nodes, where
|
||||
## RLN tree sync
|
||||
|
||||
Using RLN implies that waku should now piggyback on a blockchain (the case study uses Ethereum Sepolia) and has to stay up to date with the latest events emitted by the rln smart contract. These events are used to locally construct a tree that contains all members allowed to create valid proofs to send messages. Some numbers:
|
||||
|
||||
- A tree with 10k members takes `2Mbytes` of space. Negligible.
|
||||
- A tree with 10k members takes `<4 minutes to synchronize. Assumable since it's done just once.
|
||||
- A tree with 10k members takes `<4` minutes to synchronize. Assumable since it's done just once.
|
||||
- With a block range of 5000 blocks for each request, we would need `520 requests` to synchronize 1 year of historical data from the tree. Assumable since most of the free endpoints out there allow 100k/day.
|
||||
|
||||
## Performance relay vs. rln-relay
|
||||
|
||||
Same simulation with 100 nodes was executed `with rln` and `without rln`:
|
||||
|
||||
- Memory consumption is almost identical
|
||||
|
||||
**with rln**
|
||||
|
||||
@ -1,5 +1,4 @@
|
||||
---
|
||||
displayed_sidebar: null
|
||||
sidebar_class_name: hidden
|
||||
pagination_prev: null
|
||||
pagination_next: null
|
||||
|
||||
@ -68,22 +68,22 @@ const config = {
|
||||
type: "search",
|
||||
},
|
||||
{
|
||||
type: "docSidebar",
|
||||
position: "left",
|
||||
sidebarId: "guides",
|
||||
label: "Guides",
|
||||
to: "/",
|
||||
activeBaseRegex: "^/$|^/guides/",
|
||||
},
|
||||
{
|
||||
type: "docSidebar",
|
||||
position: "left",
|
||||
sidebarId: "learn",
|
||||
label: "Learn",
|
||||
to: "/learn/waku-network",
|
||||
activeBaseRegex: "^/learn/",
|
||||
},
|
||||
{
|
||||
type: "docSidebar",
|
||||
position: "left",
|
||||
sidebarId: "research",
|
||||
label: "Research",
|
||||
to: "/research",
|
||||
activeBaseRegex: "^/research/",
|
||||
},
|
||||
{
|
||||
href: "https://discord.waku.org",
|
||||
|
||||
20
package.json
20
package.json
@ -16,22 +16,22 @@
|
||||
"check:spell": "cspell \"**/*.{md,mdx}\""
|
||||
},
|
||||
"dependencies": {
|
||||
"@acid-info/docusaurus-fathom": "^1.0.0-alpha.111",
|
||||
"@acid-info/logos-docusaurus-preset": "^1.0.0-alpha.143",
|
||||
"@docusaurus/core": "^2.4.1",
|
||||
"@docusaurus/preset-classic": "^2.4.1",
|
||||
"@docusaurus/theme-mermaid": "^2.4.1",
|
||||
"@acid-info/docusaurus-fathom": "^1.0.3-beta.2",
|
||||
"@acid-info/logos-docusaurus-preset": "^1.0.3-beta.11",
|
||||
"@docusaurus/core": "3.8.1",
|
||||
"@docusaurus/preset-classic": "3.8.1",
|
||||
"@docusaurus/theme-mermaid": "3.8.1",
|
||||
"@emotion/react": "^11.11.0",
|
||||
"@emotion/styled": "^11.11.0",
|
||||
"@mdx-js/react": "^1.6.22",
|
||||
"@mdx-js/react": "^3.0.0",
|
||||
"add": "^2.0.6",
|
||||
"dotenv": "^16.0.3",
|
||||
"prism-react-renderer": "^1.3.5",
|
||||
"react": "^17.0.2",
|
||||
"react-dom": "^17.0.2"
|
||||
"prism-react-renderer": "^2.3.0",
|
||||
"react": "^19.0.0",
|
||||
"react-dom": "^19.0.0"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@docusaurus/module-type-aliases": "^2.4.1",
|
||||
"@docusaurus/module-type-aliases": "3.8.1",
|
||||
"@tsconfig/docusaurus": "^1.0.5",
|
||||
"cspell": "^6.16.0",
|
||||
"docusaurus-plugin-sass": "^0.2.2",
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user