fix: docs.rs url (#300)

Fixes #299 

- We have to include the version because the default one is empty(until
we publish 0.1.0 at least), but anyways it is important to explicitly
include the version.
- Add crate suffix after version, otherwise the link is still broken
- Fix crypto urls
- Add GH workflow that checks that links are not broken on `adoc`and
`md` files :)

.github/workflows/check-links.yml

@@ -0,0 +1,30 @@
+name: Check Links
+# This workflow checks that all links in the documentation are valid.
+# It does this for antora docs(adoc) and markdown files.
+# We prefer lycheeverse because it is faster, but doesn't support adoc files yet(https://github.com/lycheeverse/lychee/issues/291)
+# Because of that, we use linkspector for adoc files and lychee for md files.
+on:
+ push:
+ branches: [ main, v* ]
+ pull_request:
+ branches: [ main, v* ]
+
+jobs:
+ check-links:
+ name: Check Links
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v4
+
+ - name: Link Checker
+ uses: lycheeverse/lychee-action@v1
+ with:
+ args: --no-progress './**/*.md'
+ fail: true
+
+ - name: Run linkspector
+ uses: umbrelladocs/action-linkspector@v1
+ with:
+ fail_on_error: true
+
+

.linkspector.yml

@@ -0,0 +1,7 @@
+dirs:
+ - docs/modules/ROOT/pages/
+
+# There's a bug in linkspector that causes it to only allow one file extension type
+# when using it with directories.
+fileExtensions:
+ - adoc

docs/modules/ROOT/pages/access-control.adoc

@@ -7,7 +7,7 @@ Access control—that is, "who is allowed to do this thing"—is incredibly impo
 
 The most common and basic form of access control is the concept of _ownership_: there's an account that is the `owner` of a contract and can do administrative tasks on it. This approach is perfectly reasonable for contracts that have a single administrative user.
 
-OpenZeppelin Contracts for Stylus provides https://docs.rs/openzeppelin-stylus/latest/openzeppelin_stylus/access/ownable/struct.Ownable.html[`Ownable`] for implementing ownership in your contracts.
+OpenZeppelin Contracts for Stylus provides https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/access/ownable/struct.Ownable.html[`Ownable`] for implementing ownership in your contracts.
 
 [source,rust]
 ----
@@ -40,12 +40,12 @@ impl MyContract {
 }
 ----
 
-At deployment, the https://docs.rs/openzeppelin-stylus/latest/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.owner[`owner`] of an `Ownable` contract is set to the provided `initial_owner` parameter.
+At deployment, the https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.owner[`owner`] of an `Ownable` contract is set to the provided `initial_owner` parameter.
 
 Ownable also lets you:
 
-* https://docs.rs/openzeppelin-stylus/latest/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.transfer_ownership[`transfer_ownership`] from the owner account to a new one, and
-* https://docs.rs/openzeppelin-stylus/latest/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.renounce_ownership[`renounce_ownership`] for the owner to relinquish this administrative privilege, a common pattern after an initial stage with centralized administration is over.
+* https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.transfer_ownership[`transfer_ownership`] from the owner account to a new one, and
+* https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.renounce_ownership[`renounce_ownership`] for the owner to relinquish this administrative privilege, a common pattern after an initial stage with centralized administration is over.
 
 WARNING: Removing the owner altogether will mean that administrative tasks that are protected by `only_owner` will no longer be callable!
 
@@ -66,7 +66,7 @@ Most software uses access control systems that are role-based: some users are re
 [[using-access-control]]
 === Using `AccessControl`
 
-OpenZeppelin Contracts provides https://docs.rs/openzeppelin-stylus/latest/openzeppelin_stylus/access/control/struct.AccessControl.html[`AccessControl`] for implementing role-based access control. Its usage is straightforward: for each role that you want to define,
+OpenZeppelin Contracts provides https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/access/control/struct.AccessControl.html[`AccessControl`] for implementing role-based access control. Its usage is straightforward: for each role that you want to define,
 you will create a new _role identifier_ that is used to grant, revoke, and check if an account has that role.
 
 Here's a simple example of using `AccessControl` in an xref:erc20.adoc[ERC-20 token] to define a 'minter' role, which allows accounts that have it create new tokens. Note that the example is unassuming of the way you construct your contract.
@@ -105,7 +105,7 @@ impl Example {
 }
 ----
 
-NOTE: Make sure you fully understand how https://docs.rs/openzeppelin-stylus/latest/openzeppelin_stylus/access/control/struct.AccessControl.html[`AccessControl`] works before using it on your system, or copy-pasting the examples from this guide.
+NOTE: Make sure you fully understand how https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/access/control/struct.AccessControl.html[`AccessControl`] works before using it on your system, or copy-pasting the examples from this guide.
 
 While clear and explicit, this isn't anything we wouldn't have been able to achieve with `Ownable`. Indeed, where `AccessControl` shines is in scenarios where granular permissions are required, which can be implemented by defining _multiple_ roles.
 

docs/modules/ROOT/pages/crypto.adoc

@@ -8,11 +8,11 @@ Developers can build a Merkle Tree off-chain, which allows for verifying that an
 
 TIP: OpenZeppelin Contracts provides a https://github.com/OpenZeppelin/merkle-tree[JavaScript library] for building trees off-chain and generating proofs.
 
-https://docs.rs/crypto/latest/merkle/struct.Verifier.html[`MerkleProof`] provides:
+https://docs.rs/openzeppelin-crypto/0.1.0-rc/openzeppelin_crypto/merkle/struct.Verifier.html[`MerkleProof`] provides:
 
-* https://docs.rs/crypto/latest/merkle/struct.Verifier.html#method.verify[`verify`] - can prove that some value is part of a https://en.wikipedia.org/wiki/Merkle_tree[Merkle tree].
+* https://docs.rs/openzeppelin-crypto/0.1.0-rc/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify[`verify`] - can prove that some value is part of a https://en.wikipedia.org/wiki/Merkle_tree[Merkle tree].
 
-* https://docs.rs/crypto/latest/merkle/struct.Verifier.html#method.verify_multi_proof[`verify_multi_proof`] - can prove multiple values are part of a Merkle tree.
+* https://docs.rs/openzeppelin-crypto/0.1.0-rc/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify_multi_proof[`verify_multi_proof`] - can prove multiple values are part of a Merkle tree.
 
 [source,rust]
 ----
@@ -22,6 +22,6 @@ pub fn verify(&self, proof: Vec<B256>, root: B256, leaf: B256) -> bool {
 }
 ----
 
-Note that these functions use `keccak256` as the hashing algorithm, but our library also provides generic counterparts: https://docs.rs/crypto/latest/merkle/struct.Verifier.html#method.verify_with_builder[`verify_with_builer`] and https://docs.rs/crypto/latest/merkle/struct.Verifier.html#method.verify_multi_proof_with_builder[`verify_multi_proof_with_builder`].
+Note that these functions use `keccak256` as the hashing algorithm, but our library also provides generic counterparts: https://docs.rs/openzeppelin-crypto/0.1.0-rc/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify_with_builder[`verify_with_builer`] and https://docs.rs/openzeppelin-crypto/0.1.0-rc/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify_multi_proof_with_builder[`verify_multi_proof_with_builder`].
 
-We also provide an adapter https://docs.rs/crypto/latest/hash/index.html[`hash`] module to use your own hashers in conjunction with them that resembles Rust's standard library's API.
+We also provide an adapter https://docs.rs/openzeppelin-crypto/0.1.0-rc/openzeppelin_crypto/hash/index.html[`hash`] module to use your own hashers in conjunction with them that resembles Rust's standard library's API.

docs/modules/ROOT/pages/erc20-burnable.adoc

@@ -5,7 +5,7 @@ Extension of xref:erc20.adoc[ERC-20] that allows token holders to destroy both t
 [[usage]]
 == Usage
 
-In order to make https://docs.rs/openzeppelin_stylus/token/erc20/extensions/burnable/index.html[`ERC-20 Burnable`] methods “external” so that other contracts can call them, you need to implement them by yourself for your final contract as follows:
+In order to make https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc20/extensions/burnable/index.html[`ERC-20 Burnable`] methods “external” so that other contracts can call them, you need to implement them by yourself for your final contract as follows:
 
 [source,rust]
 ----

docs/modules/ROOT/pages/erc20-capped.adoc

@@ -5,7 +5,7 @@ Extension of xref:erc20.adoc[ERC-20] that adds a cap to the supply of tokens.
 [[usage]]
 == Usage
 
-In order to make https://docs.rs/openzeppelin_stylus/token/erc20/extensions/capped/index.html[`ERC-20 Capped`] methods supervising the supply of tokens, you need to add them by yourself for your final contract as follows:
+In order to make https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc20/extensions/capped/index.html[`ERC-20 Capped`] methods supervising the supply of tokens, you need to add them by yourself for your final contract as follows:
 
 [source,rust]
 ----

docs/modules/ROOT/pages/erc20-metadata.adoc

@@ -5,7 +5,7 @@ Extension of xref:erc20.adoc[ERC-20] that adds the optional metadata functions f
 [[usage]]
 == Usage
 
-In order to make https://docs.rs/openzeppelin_stylus/token/erc20/extensions/metadata/index.html[`ERC-20 Metadata`] methods “external” so that other contracts can call them, you need to add the following code to your contract:
+In order to make https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc20/extensions/metadata/index.html[`ERC-20 Metadata`] methods “external” so that other contracts can call them, you need to add the following code to your contract:
 
 [source,rust]
 ----

docs/modules/ROOT/pages/erc20-pausable.adoc

@@ -7,7 +7,7 @@ Useful for scenarios such as preventing trades until the end of an evaluation pe
 [[usage]]
 == Usage
 
-In order to make your ERC20 token `pausable`, you need to use the https://docs.rs/openzeppelin_stylus/utils/pausable/index.html[`Pausable`] contract and apply its mechanisms to ERC20 token functions as follows:
+In order to make your ERC20 token `pausable`, you need to use the https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/utils/pausable/index.html[`Pausable`] contract and apply its mechanisms to ERC20 token functions as follows:
 
 [source,rust]
 ----

docs/modules/ROOT/pages/erc20-permit.adoc

@@ -1,13 +1,13 @@
 = ERC-20 Permit
 Implementation of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[`EIP-2612`].
 
-Adds the permit method, which can be used to change an account’s ERC20 allowance (see https://docs.rs/openzeppelin_stylus/token/erc20/trait.IErc20.html#tymethod.allowance[`IErc20::allowance`]) by presenting a message signed by the account. By not relying on https://docs.rs/openzeppelin_stylus/token/erc20/trait.IErc20.html#tymethod.approve[`IErc20::approve`], the token holder account doesn’t need to send a transaction, and thus is not required to hold Ether at all.
+Adds the permit method, which can be used to change an account’s ERC20 allowance (see https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc20/trait.IErc20.html#tymethod.allowance[`IErc20::allowance`]) by presenting a message signed by the account. By not relying on https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc20/trait.IErc20.html#tymethod.approve[`IErc20::approve`], the token holder account doesn’t need to send a transaction, and thus is not required to hold Ether at all.
 
 
 [[usage]]
 == Usage
 
-In order to have https://docs.rs/openzeppelin_stylus/token/erc20/extensions/permit/index.html[`ERC-20 Permit`] token, you need to use only this contract without xref:erc20.adoc[ERC-20] as follows:
+In order to have https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc20/extensions/permit/index.html[`ERC-20 Permit`] token, you need to use only this contract without xref:erc20.adoc[ERC-20] as follows:
 
 [source,rust]
 ----

docs/modules/ROOT/pages/erc20.adoc

@@ -4,7 +4,7 @@ An ERC-20 token contract keeps track of xref:tokens.adoc#different-kinds-of-toke
 This makes ERC-20 tokens useful for things like a *medium of exchange currency*, *voting rights*, *staking*, and more.
 
 OpenZeppelin Contracts provide many ERC20-related contracts for Arbitrum Stylus.
-On the https://docs.rs/openzeppelin_stylus/token/erc20/struct.Erc20.html[`API reference`] you'll find detailed information on their properties and usage.
+On the https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc20/struct.Erc20.html[`API reference`] you'll find detailed information on their properties and usage.
 
 [[constructing-an-erc20-token-contract]]
 == Constructing an ERC-20 Token Contract
@@ -30,7 +30,7 @@ sol_storage! {
 impl GLDToken {}
 ----
 
-Our contracts are often used via stylus-sdk https://docs.arbitrum.io/stylus/reference/rust-sdk-guide#inheritance-inherit-and-borrow[inheritance], and here we're reusing https://docs.rs/openzeppelin_stylus/token/erc20/struct.Erc20.html[`ERC20`] for both the basic standard implementation and with optional extensions.
+Our contracts are often used via stylus-sdk https://docs.arbitrum.io/stylus/reference/rust-sdk-guide#inheritance-inherit-and-borrow[inheritance], and here we're reusing https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc20/struct.Erc20.html[`ERC20`] for both the basic standard implementation and with optional extensions.
 
 [[a-note-on-decimals]]
 == A Note on `decimals`
@@ -39,7 +39,7 @@ Often, you'll want to be able to divide your tokens into arbitrary amounts: say,
 Unfortunately, Solidity and the EVM do not support this behavior: only integer (whole) numbers can be used, which poses an issue.
 You may send `1` or `2` tokens, but not `1.5`.
 
-To work around this, ERC20 provides a https://docs.rs/openzeppelin_stylus/token/erc20/extensions/metadata/trait.IErc20Metadata.html#tymethod.decimals[`decimals`] field, which is used to specify how many decimal places a token has.
+To work around this, ERC20 provides a https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc20/extensions/metadata/trait.IErc20Metadata.html#tymethod.decimals[`decimals`] field, which is used to specify how many decimal places a token has.
 To be able to transfer `1.5 GLD`, `decimals` must be at least `1`, since that number has a single decimal place.
 
 How can this be achieved?

docs/modules/ROOT/pages/erc721-burnable.adoc

@@ -5,7 +5,7 @@ xref:erc721.adoc[ERC-721] Token that can be burned (destroyed).
 [[usage]]
 == Usage
 
-In order to make https://docs.rs/openzeppelin_stylus/token/erc721/extensions/burnable/index.html[`ERC-721 Burnable`] methods “external” so that other contracts can call them, you need to implement them by yourself for your final contract as follows:
+In order to make https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc721/extensions/burnable/index.html[`ERC-721 Burnable`] methods “external” so that other contracts can call them, you need to implement them by yourself for your final contract as follows:
 
 [source,rust]
 ----

docs/modules/ROOT/pages/erc721-consecutive.adoc

@@ -5,7 +5,7 @@ Consecutive extension for xref:erc721.adoc[ERC-721] is useful for efficiently mi
 [[usage]]
 == Usage
 
-In order to make https://docs.rs/openzeppelin_stylus/token/erc721/extensions/consecutive/index.html[`ERC-721 Consecutive`] methods “external” so that other contracts can call them, you need to add the following code to your contract:
+In order to make https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc721/extensions/consecutive/index.html[`ERC-721 Consecutive`] methods “external” so that other contracts can call them, you need to add the following code to your contract:
 
 [source,rust]
 ----

docs/modules/ROOT/pages/erc721-enumerable.adoc

@@ -5,7 +5,7 @@ The OpenZeppelin xref:erc721.adoc[ERC-721] Enumerable extension is used to provi
 [[usage]]
 == Usage
 
-In order to make an xref:erc721.adoc[ERC-721] token with https://docs.rs/openzeppelin_stylus/token/erc721/extensions/enumerable/index.html[Enumerable] flavour,
+In order to make an xref:erc721.adoc[ERC-721] token with https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc721/extensions/enumerable/index.html[Enumerable] flavour,
 you need to create a specified contract as follows:
 
 [source,rust]

docs/modules/ROOT/pages/erc721-metadata.adoc

@@ -5,7 +5,7 @@ Extension of xref:erc721.adoc[ERC-721] that adds the optional metadata functions
 [[usage]]
 == Usage
 
-In order to make https://docs.rs/openzeppelin_stylus/token/erc721/extensions/metadata/index.html[`ERC-721 Metadata`] methods “external” so that other contracts can call them, you need to add the following code to your contract:
+In order to make https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc721/extensions/metadata/index.html[`ERC-721 Metadata`] methods “external” so that other contracts can call them, you need to add the following code to your contract:
 
 [source,rust]
 ----

docs/modules/ROOT/pages/erc721-pausable.adoc

@@ -7,7 +7,7 @@ Useful for scenarios such as preventing trades until the end of an evaluation pe
 [[usage]]
 == Usage
 
-In order to make your ERC721 token `pausable`, you need to use the https://docs.rs/openzeppelin_stylus/utils/pausable/index.html[`Pausable`] contract and apply its mechanisms to ERC721 token functions as follows:
+In order to make your ERC721 token `pausable`, you need to use the https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/utils/pausable/index.html[`Pausable`] contract and apply its mechanisms to ERC721 token functions as follows:
 
 [source,rust]
 ----

docs/modules/ROOT/pages/erc721-uri-storage.adoc

@@ -7,8 +7,8 @@ This is particularly useful for non-fungible tokens (NFTs) where each token is u
 [[usage]]
 == Usage
 
-In order to make an xref:erc721.adoc[ERC-721] token with https://docs.rs/openzeppelin_stylus/token/erc721/extensions/uri_storage/index.html[URI Storage] flavour,
-your token should also use https://docs.rs/openzeppelin_stylus/token/erc721/extensions/metadata/index.html[`ERC-721 Metadata`] extension to provide additional metadata for each token.
+In order to make an xref:erc721.adoc[ERC-721] token with https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc721/extensions/uri_storage/index.html[URI Storage] flavour,
+your token should also use https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc721/extensions/metadata/index.html[`ERC-721 Metadata`] extension to provide additional metadata for each token.
 You need to create a specified contract as follows:
 
 [source,rust]

docs/modules/ROOT/pages/erc721.adoc

@@ -6,7 +6,7 @@ ERC-721 is a standard for representing ownership of xref:tokens.adoc#different-k
 
 ERC-721 is a more complex standard than ERC-20, with multiple optional extensions, and is split across a number of contracts.
 The OpenZeppelin Contracts provide flexibility regarding how these are combined, along with custom useful extensions.
-Check out the https://docs.rs/openzeppelin_stylus/token/erc721/struct.Erc721.html[`API reference`] to learn more about these.
+Check out the https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc721/struct.Erc721.html[`API reference`] to learn more about these.
 
 == Constructing an ERC-721 Token Contract
 
@@ -49,7 +49,7 @@ impl GameItem {
 }
 ----
 
-The https://docs.rs/openzeppelin_stylus/token/erc721/extensions/metadata/struct.Erc721Metadata.html[`Erc721Metadata`] contract is an extension contract of ERC-721.
+The https://docs.rs/openzeppelin-stylus/0.1.0-rc/openzeppelin_stylus/token/erc721/extensions/metadata/struct.Erc721Metadata.html[`Erc721Metadata`] contract is an extension contract of ERC-721.
 It extends the contract itself with the name, symbol and base uri for the token.
 
 Also note that, unlike ERC-20, ERC-721 lacks a `decimals` field, since each token is distinct and cannot be partitioned.