Merge remote-tracking branch 'origin/main' into nialexsan/fix-anchors

docs/build/basics/fees.md

@@ -328,7 +328,7 @@ access(all) fun add(_ a: Int, _ b: Int): Int {
 
 **Avoid excessive load and save operations**
 
-Avoid costly loading and storage operations and [borrow references](https://cadence-lang.org/docs/1.0/design-patterns#avoid-excessive-load-and-save-storage-operations-prefer-in-place-mutations) where possible, for example:
+Avoid costly loading and storage operations and [borrow references](https://cadence-lang.org/docs/design-patterns#avoid-excessive-load-and-save-storage-operations-prefer-in-place-mutations) where possible, for example:
 
 ```cadence
 transaction {

docs/build/core-contracts/02-fungible-token.md

@@ -6,7 +6,7 @@ sidebar_label: Fungible Token
 
 The `FungibleToken` contract implements the Fungible Token Standard. It is the second contract ever deployed on Flow.
 
-- [Basic Fungible Token Tutorial](https://cadence-lang.org/docs/1.0/tutorial/fungible-tokens)
+- [Basic Fungible Token Tutorial](https://cadence-lang.org/docs/tutorial/fungible-tokens)
 - [Fungible Token Guide](../guides/fungible-token.md)
 - [Fungible Token Standard Repo](https://github.com/onflow/flow-ft)
 

docs/build/core-contracts/08-non-fungible-token.md

@@ -7,7 +7,7 @@ sidebar_label: Non-Fungible Token
 The `NonFungibleToken` contract interface implements the Fungible Token Standard.
 All NFT contracts are encouraged to import and implement this standard.
 
-- [Basic Non-Fungible Token Tutorial](https://cadence-lang.org/docs/1.0/tutorial/non-fungible-tokens-1)
+- [Basic Non-Fungible Token Tutorial](https://cadence-lang.org/docs/tutorial/non-fungible-tokens-1)
 - [Non Fungible Token Guide](../guides/nft.md)
 - [Non Fungible Token Standard Repo](https://github.com/onflow/flow-nft)
 

docs/build/differences-vs-evm/index.md

@@ -185,7 +185,6 @@ If you're already familiar with blockchain development, here's a comparison betw
 - [Testing Smart Contracts](https://ethereum.org/en/developers/docs/smart-contracts/testing/)
   - [Cadence testing framework](https://cadence-lang.org/docs/testing-framework) enables native tests in Cadence.
   - [overflow](https://github.com/bjartek/overflow) for testing in Go.
-  - [js-testing](https://github.com/onflow/flow-js-testing) for testing in JS.
 
 <!-- Relative-style links.  Does not render on the page -->
 
@@ -200,7 +199,7 @@ If you're already familiar with blockchain development, here's a comparison betw
 [Cadence]: https://cadence-lang.org/
 [Resources]: https://cadence-lang.org/docs/language/resources
 [Capability-based Security]: https://en.wikipedia.org/wiki/Capability-based_security
-[Entitlements]: https://cadence-lang.org/docs/1.0/language/access-control#entitlements
+[Entitlements]: https://cadence-lang.org/docs/language/access-control#entitlements
 [Capability-based Access Control]: https://cadence-lang.org/docs/language/capabilities
 [Guide for Solidity Developers]: https://cadence-lang.org/docs/solidity-to-cadence
 [The Cadence tutorial]: https://cadence-lang.org/docs/tutorial/first-steps
@@ -209,4 +208,4 @@ If you're already familiar with blockchain development, here's a comparison betw
 [Scripts]: ../basics/scripts.md
 [Transactions]: https://cadence-lang.org/docs/language/transactions
 [Flow Primer]: https://flow.com/primer#primer-how-flow-works
-[via an API]: ../../networks/flow-networks/index.md
+[via an API]: ../../networks/flow-networks/index.md

docs/build/guides/account-linking/index.md

@@ -11,7 +11,7 @@ order to understand how we can achieve that we must first understand how account
 Accounts on flow can be accessed in Cadence through two types, `PublicAccount` and `Account`. As the name implies the
 `PublicAccount` type gives access to all public account information such as address, balance, storage capacity, etc.,
 but doesn't allow changes to the account. The `Account` type (or more specifically, an
-[entitled](https://cadence-lang.org/docs/1.0/language/access-control#entitlements) `&Account`) allows the same access as
+[entitled](https://cadence-lang.org/docs/language/access-control#entitlements) `&Account`) allows the same access as
 `PublicAccount` but also allows changes to the account, including adding/revoking account keys, managing the deployed
 contracts, as well as linking and publishing Capabilities.
 

docs/build/guides/fungible-token.md

@@ -23,8 +23,8 @@ Resources are objects in Cadence that store data,
 but have special restrictions about how they can be stored and transferred,
 making them perfect for representing digital objects with real value.
 
-You can learn more about resources in the Cadence [documentation](https://cadence-lang.org/docs/1.0/language/resources)
-and [tutorials](https://cadence-lang.org/docs/1.0/tutorial/resources).
+You can learn more about resources in the Cadence [documentation](https://cadence-lang.org/docs/language/resources)
+and [tutorials](https://cadence-lang.org/docs/tutorial/resources).
 
 For fungible tokens specifically, tokens are represented by a resource type called a `Vault`:
 
@@ -277,7 +277,7 @@ access(all) contract FooToken: FungibleToken {
 
 As you can see, this function has an `access(FungibleToken.Withdraw)` access modifier.
 This is an example of entitlements in Cadence.
-[Entitlements](https://cadence-lang.org/docs/1.0/language/access-control#entitlements)
+[Entitlements](https://cadence-lang.org/docs/language/access-control#entitlements)
 are a way for developers to restrict access to privileged fields and functions
 in a composite type like a resource when a reference is created for it.
 In this example, the `withdraw()` function is always accessible to code that
@@ -294,15 +294,15 @@ defined by the FungibleToken contract:
 
 Entitlements are important to understand because they are what protects
 privileged functionality in your resource objects from being accessed by third-parties.
-It is recommended to read the [entitlements documentation](https://cadence-lang.org/docs/1.0/language/access-control#entitlements)
+It is recommended to read the [entitlements documentation](https://cadence-lang.org/docs/language/access-control#entitlements)
 to understand how to use the feature properly.
 
-[References](https://cadence-lang.org/docs/1.0/language/references) can be freely up-casted and down-casted in Cadence, so it is important
+[References](https://cadence-lang.org/docs/language/references) can be freely up-casted and down-casted in Cadence, so it is important
 for privileged functionality to be protected by an entitlement so that it can
 only be accessed if it is authorized.
 
 In addition to withdrawing, the vault also needs a way to deposit.
-We'll [typecast](https://cadence-lang.org/docs/1.0/language/operators#casting-operators)
+We'll [typecast](https://cadence-lang.org/docs/language/operators#casting-operators)
 to make sure we are dealing with the correct token, update the vault balance,
 and destroy the vault. Add this code to your resource:
 

docs/build/guides/nft.md

@@ -366,7 +366,7 @@ access(all) resource Collection: NonFungibleToken.Collection {
 
 As you can see, this function has an `access(NonFungibleToken.Withdraw)` access modifier.
 This is an example of entitlements in Cadence.
-[Entitlements](https://cadence-lang.org/docs/1.0/language/access-control#entitlements)
+[Entitlements](https://cadence-lang.org/docs/language/access-control#entitlements)
 are a way for developers to restrict access to privileged fields and functions
 in a composite type like a resource when a reference is created for it.
 In this example, the `withdraw()` function is always accessible to code that
@@ -383,10 +383,10 @@ defined by the `NonFungibleToken` contract:
 
 Entitlements are important to understand because they are what protects
 privileged functionality in your resource objects from being accessed by third-parties.
-It is recommended to read the [entitlements documentation](https://cadence-lang.org/docs/1.0/language/access-control#entitlements)
+It is recommended to read the [entitlements documentation](https://cadence-lang.org/docs/language/access-control#entitlements)
 to understand how to use the feature properly.
 
-[References](https://cadence-lang.org/docs/1.0/language/references) can be freely up-casted and down-casted in Cadence, so it is important
+[References](https://cadence-lang.org/docs/language/references) can be freely up-casted and down-casted in Cadence, so it is important
 for privileged functionality to be protected by an entitlement so that it can
 only be accessed if it is authorized.
 

docs/build/smart-contracts/best-practices/project-development-tips.md

@@ -173,7 +173,6 @@ which are noteworthy to mention for a typical smart contract project.
 
 Popular testing frameworks to use for cadence are listed here:
 - Cadence: [Cadence Testing Framework](../../smart-contracts/testing.md)
-- Javascript: [Flow JS Testing](../../../tools/flow-js-testing/index.md)
 - Go: [Overflow](https://github.com/bjartek/overflow)
 
 The same person who writes the code should also write the tests.
@@ -284,8 +283,8 @@ It also helps the owner to promote the project and themselves.
 
 Resources for Best Practices:
 
-- [cadence/design-pattern](https://cadence-lang.org/docs/1.0/design-patterns)
-- [cadence/anti-patterns](https://cadence-lang.org/docs/1.0/anti-patterns)
+- [cadence/design-pattern](https://cadence-lang.org/docs/design-patterns)
+- [cadence/anti-patterns](https://cadence-lang.org/docs/anti-patterns)
 - [cadence/security-best-practices](./security-best-practices.md)
 
 Composability and extensibility should also be priorities while designing, developing,

docs/build/smart-contracts/best-practices/security-best-practices.md

@@ -6,7 +6,7 @@ sidebar_position: 3
 
 This is an opinionated list of best practices Cadence developers should follow to write more secure Cadence code.
 
-Some practices listed below might overlap with advice in the [Cadence Anti-Patterns](https://cadence-lang.org/docs/1.0/design-patterns) section, which is a recommended read as well.
+Some practices listed below might overlap with advice in the [Cadence Anti-Patterns](https://cadence-lang.org/docs/design-patterns) section, which is a recommended read as well.
 
 ## References
 
@@ -31,7 +31,7 @@ Always [borrow](https://cadence-lang.org/docs/language/capabilities) with the sp
 
 Access to an `&Account` gives access to whatever is specified in the account entitlements
 list when that account reference is created.
-Therefore, [avoid using Account references](https://cadence-lang.org/docs/1.0/anti-patterns#avoid-using-authaccount-as-a-function-parameter) as a function parameter or field unless absolutely necessary and only use the minimal set of entitlements required
+Therefore, [avoid using Account references](https://cadence-lang.org/docs/anti-patterns#avoid-using-authaccount-as-a-function-parameter) as a function parameter or field unless absolutely necessary and only use the minimal set of entitlements required
 for the specified functionality so that other account functionality cannot be accessed.
 
 It is preferable to use capabilities over direct `&Account` references when exposing account data. Using capabilities allows the revocation of access by unlinking and limits the access to a single value with a certain set of functionality.

docs/build/smart-contracts/overview.md

@@ -26,7 +26,6 @@ To build confidently, you will want to set up the appropriate local environment
 - [Flow Emulator](../../tools/emulator/index.md): A lightweight server that simulates the Flow blockchain (strongly recommended during development).
 - [Flow Dev Wallet](https://github.com/onflow/fcl-dev-wallet/): A utility to simulate user wallets in development.
 - [Visual Studio Code Extension](../../tools/vscode-extension/index.md): An IDE integration for developing smart contracts.
-- [JS Testing Framework](https://github.com/onflow/flow-js-testing): A framework to test your smart contracts.
 
 ## Storing Data on Flow
 

docs/build/smart-contracts/testing.md

@@ -250,26 +250,20 @@ You can find examples of Go tests in the following projects: [flow-core-contract
 These tests are tied to the emulator but can be refactored to run on testnet
 </Callout>
 
-### JavaScript Tests
-
-Tests in JavaScript can be written using [flow-js-testing](https://github.com/onflow/flow-js-testing).
-
-It is critical to test your applications and contracts thoroughly on the testnet as part of your road to the mainnet. Testing will help you understand how to create stable and robust applications using the Flow development stack.
-
 ## Testing Your Application
 
 ### Automated Testing of Contract Code
 
 All contracts should include test coverage for _all contract functions_. Make sure you've accounted for success and failure cases appropriately.
 
-Tests should also be runnable in automated environments (CI). You can use the [JavaScript testing framework](https://github.com/onflow/flow-js-testing) to create tests for your smart contract code.
+Tests should also be runnable in automated environments (CI). You can use the [Cadence testing utils](https://cadence-lang.org/docs/testing-framework) to create tests for your smart contract code.
 
 ### Stress Testing Live Applications Before Mainnet
 
 Once you deployed your application to the testnet, you should record how your application handles non-trivial amounts of traffic to ensure there are no issues.
 
 <Callout type="success">
-Get familiar with the [Cadence anti-patterns](https://cadence-lang.org/docs/1.0/anti-patterns) to avoid avoid problematic or unintended behavior.
+Get familiar with the [Cadence anti-patterns](https://cadence-lang.org/docs/anti-patterns) to avoid avoid problematic or unintended behavior.
 </Callout>
 
 

docs/evm/accounts.md

@@ -16,7 +16,7 @@ There are three types of accounts used for EVM on Flow.
 
 1. **Externally Owned Accounts (EOA)**: EOAs are controlled by private individuals using cryptographic keys and can initiate transactions directly. They are the primary account type for users to interact with the blockchain, holding and sending cryptocurrency or calling smart contract functions.
 2. **Contract Accounts**: These accounts hold smart contract code and are governed by this code's logic. Unlike EOAs, Contract Accounts do not initiate transactions on their own but can execute transactions in response to calls they receive from EOAs or other contracts.
-3. **Cadence Owned Accounts (COA)**: This is an account type unique to Flow EVM. These accounts are managed by [Cadence resources](https://cadence-lang.org/docs/1.0/language/resources) and can be used to interact with the Flow EVM from within the Cadence environment.
+3. **Cadence Owned Accounts (COA)**: This is an account type unique to Flow EVM. These accounts are managed by [Cadence resources](https://cadence-lang.org/docs/language/resources) and can be used to interact with the Flow EVM from within the Cadence environment.
 
 EOAs and Contract accounts function the same as on other EVM networks. Users may interact with these accounts using the standard EVM JSON-RPC API ([see endpoints here](./using.mdx)). You can read more about EOAs and Contract accounts on the [Ethereum docs](https://ethereum.org/developers/docs/accounts).
 
@@ -38,7 +38,7 @@ COAs create powerful new opportunities to improve the UX, functionality and util
 
 - **Native Account Abstraction**: COAs are controlled by Cadence resources, which are in turn owned by Flow accounts. [Flow accounts](./accounts.md) have built-in support for multi-signature authentication, key rotation, and account recovery. As a Cadence resource, COAs naturally inherit [these features](../build/advanced-concepts/account-abstraction.md).
 
-- **Fine-Grained Access Control**: As Cadence resources, access to a COA can be governed by more sophisticated policies than those available with basic EVM accounts. By utilizing powerful Cadence access control primitives such as [capabilities and entitlements](https://cadence-lang.org/docs/1.0/language/access-control), developers can restrict who is able to interact with a COA and what actions they are permitted to perform.
+- **Fine-Grained Access Control**: As Cadence resources, access to a COA can be governed by more sophisticated policies than those available with basic EVM accounts. By utilizing powerful Cadence access control primitives such as [capabilities and entitlements](https://cadence-lang.org/docs/language/access-control), developers can restrict who is able to interact with a COA and what actions they are permitted to perform.
 
 ### Differences from Traditional EVM Accounts