fix links and redirects

docs/build/building-apps/01-app-go-v2.md

@@ -7,7 +7,7 @@ sidebar_position: 1
 
 :::note Synopsis
 
-The Cosmos SDK allows much easier wiring of an `app.go` thanks to App Wiring and [`depinject`](../libraries/01-depinject.md).
+The Cosmos SDK allows much easier wiring of an `app.go` thanks to App Wiring and [`depinject`](../packages/01-depinject.md).
 Learn more about the rationale of App Wiring in [ADR-057](../architecture/adr-057-app-wiring.md).
 
 :::
@@ -17,7 +17,7 @@ Learn more about the rationale of App Wiring in [ADR-057](../architecture/adr-05
 ### Pre-requisite Readings
 
 * [ADR 057: App Wiring](../architecture/adr-057-app-wiring.md)
-* [Depinject Documentation](../libraries/01-depinject.md)
+* [Depinject Documentation](../packages/01-depinject.md)
 * [Modules depinject-ready](../building-modules/15-depinject.md)
 
 :::

docs/build/building-modules/15-depinject.md

@@ -8,11 +8,11 @@ sidebar_position: 1
 
 ### Pre-requisite Readings
 
-* [Depinject Documentation](../libraries/01-depinject.md)
+* [Depinject Documentation](../packages/01-depinject.md)
 
 :::
 
-[`depinject`](../libraries/01-depinject.md) is used to wire any module in `app.go`.
+[`depinject`](../packages/01-depinject.md) is used to wire any module in `app.go`.
 All core modules are already configured to support dependency injection.
 
 To work with `depinject` a module must define its configuration and requirements so that `depinject` can provide the right dependencies.

docs/build/building-modules/16-testing.md

@@ -86,7 +86,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/tests/integration/bank/kee
 
 ## Simulations
 
-Simulations uses as well a minimal application, built with [`depinject`](../libraries/01-depinject.md):
+Simulations uses as well a minimal application, built with [`depinject`](../packages/01-depinject.md):
 
 :::note
 You can as well use the `AppConfig` `configurator` for creating an `AppConfig` [inline](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/slashing/app_test.go#L54-L62). There is no difference between those two ways, use whichever you prefer.

docs/build/modules/README.md

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 0
-slug : /modules
 ---
 
 # Module Summary

docusaurus.config.js

@@ -451,7 +451,7 @@ function generateRedirects(version) {
     },
     {
       from: `/${version}/building-modules`,
-      to: `/${version}/build/building-modules/app-go`,
+      to: `/${version}/build/building-modules/intro`,
     },
     {
       from: `/${version}/modules`,

versioned_docs/version-0.47/build/building-apps/01-app-go-v2.md

@@ -7,7 +7,7 @@ sidebar_position: 1
 
 :::note Synopsis
 
-The Cosmos SDK allows much easier wiring of an `app.go` thanks to App Wiring and [`depinject`](../libraries/01-depinject.md).
+The Cosmos SDK allows much easier wiring of an `app.go` thanks to App Wiring and [`depinject`](../packages/01-depinject.md).
 Learn more about the rationale of App Wiring in [ADR-057](../architecture/adr-057-app-wiring.md).
 
 :::
@@ -17,7 +17,7 @@ Learn more about the rationale of App Wiring in [ADR-057](../architecture/adr-05
 ### Pre-requisite Readings
 
 * [ADR 057: App Wiring](../architecture/adr-057-app-wiring.md)
-* [Depinject Documentation](../libraries/01-depinject.md)
+* [Depinject Documentation](../packages/01-depinject.md)
 * [Modules depinject-ready](../building-modules/15-depinject.md)
 
 :::

versioned_docs/version-0.47/build/building-modules/15-depinject.md

@@ -8,11 +8,11 @@ sidebar_position: 1
 
 ### Pre-requisite Readings
 
-* [Depinject Documentation](../libraries/01-depinject.md)
+* [Depinject Documentation](../packages/01-depinject.md)
 
 :::
 
-[`depinject`](../libraries/01-depinject.md) is used to wire any module in `app.go`.
+[`depinject`](../packages/01-depinject.md) is used to wire any module in `app.go`.
 All core modules are already configured to support dependency injection.
 
 To work with `depinject` a module must define its configuration and requirements so that `depinject` can provide the right dependencies.

versioned_docs/version-0.47/build/building-modules/16-testing.md

@@ -86,7 +86,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/tests/integration/bank/kee
 
 ## Simulations
 
-Simulations uses as well a minimal application, built with [`depinject`](../libraries/01-depinject.md):
+Simulations uses as well a minimal application, built with [`depinject`](../packages/01-depinject.md):
 
 :::note
 You can as well use the `AppConfig` `configurator` for creating an `AppConfig` [inline](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/slashing/app_test.go#L54-L62). There is no difference between those two ways, use whichever you prefer.

versioned_docs/version-0.47/build/modules/README.md

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 0
-slug : /modules
 ---
 
 # Module Summary

versioned_docs/version-0.50/build/building-modules/00-intro.md

@@ -10,7 +10,7 @@ Modules define most of the logic of Cosmos SDK applications. Developers compose
 
 :::note Pre-requisite Readings
 
-* [Anatomy of a Cosmos SDK application](../../develop/beginner/00-app-anatomy.md)
+* [Anatomy of a Cosmos SDK application](../../develop/beginner/00-overview-app.md)
 * [Lifecycle of a Cosmos SDK transaction](../../develop/beginner/01-tx-lifecycle.md)
 
 :::

versioned_docs/version-0.50/build/building-modules/01-module-manager.md

@@ -5,7 +5,7 @@ sidebar_position: 1
 # Module Manager
 
 :::note Synopsis
-Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../../develop/advanced/00-baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](../../develop/beginner/00-app-anatomy#preblocker) and [`BeginBlocker` and `EndBlocker`](../../develop/beginner/00-app-anatomy.md#begingblocker-and-endblocker).
+Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../../develop/advanced/00-baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](../../develop/beginner/00-app-anatomy#preblocker) and [`BeginBlocker` and `EndBlocker`](../../develop/beginner/00-overview-app.md#begingblocker-and-endblocker).
 :::
 
 :::note Pre-requisite Readings
@@ -46,7 +46,7 @@ The above interfaces are mostly embedding smaller interfaces (extension interfac
 * (legacy) [`module.HasInvariants`](#hasinvariants): The extension interface for registering invariants.
 * (legacy) [`module.HasConsensusVersion`](#hasconsensusversion): The extension interface for declaring a module consensus version.
 
-The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](../../develop/beginner/00-app-anatomy.md#core-application-file).
+The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](../../develop/beginner/00-overview-app.md#core-application-file).
 
 The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interact with other modules, typically through [`keeper`s](./06-keeper.md), which means there is a need for an interface where modules list their `keeper`s and other methods that require a reference to another module's object. `AppModule` interface extension, such as `HasBeginBlocker` and `HasEndBlocker`, also enables the module manager to set the order of execution between module's methods like `BeginBlock` and `EndBlock`, which is important in cases where the order of execution between modules matters in the context of the application.
 
@@ -272,9 +272,9 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/types/module/module.go
 
 It implements the following methods:
 
-* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](../../develop/beginner/00-app-anatomy.md#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example).
+* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](../../develop/beginner/00-overview-app.md#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example).
 * `NewBasicManagerFromManager(manager *Manager, customModuleBasics map[string]AppModuleBasic)`: Contructor function. It creates a new `BasicManager` from a `Manager`. The `BasicManager` will contain all `AppModuleBasic` from the `AppModule` manager using `CoreAppModuleBasicAdaptor` whenever possible. Module's `AppModuleBasic` can be overridden by passing a custom AppModuleBasic map
-* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](../../develop/advanced/05-encoding.md#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](../../develop/beginner/00-app-anatomy.md#constructor).
+* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](../../develop/advanced/05-encoding.md#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](../../develop/beginner/00-overview-app.md#constructor).
 * `RegisterInterfaces(registry codectypes.InterfaceRegistry)`: Registers interface types and implementations of each of the application's `AppModuleBasic`.
 * `DefaultGenesis(cdc codec.JSONCodec)`: Provides default genesis information for modules in the application by calling the [`DefaultGenesis(cdc codec.JSONCodec)`](./08-genesis.md#defaultgenesis) function of each module. It only calls the modules that implements the `HasGenesisBasics` interfaces.
 * `ValidateGenesis(cdc codec.JSONCodec, txEncCfg client.TxEncodingConfig, genesis map[string]json.RawMessage)`: Validates the genesis information modules by calling the [`ValidateGenesis(codec.JSONCodec, client.TxEncodingConfig, json.RawMessage)`](./08-genesis.md#validategenesis) function of modules implementing the `HasGenesisBasics` interface.
@@ -292,15 +292,15 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/types/module/module.go
 
 The module manager is used throughout the application whenever an action on a collection of modules is required. It implements the following methods:
 
-* `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](../../develop/beginner/00-app-anatomy.md#constructor-function).
-* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](./08-genesis.md#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](../../develop/beginner/00-app-anatomy.md#constructor-function).
+* `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](../../develop/beginner/00-overview-app.md#constructor-function).
+* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](./08-genesis.md#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](../../develop/beginner/00-overview-app.md#constructor-function).
   To initialize modules successfully, module dependencies should be considered. For example, the `genutil` module must occur after `staking` module so that the pools are properly initialized with tokens from genesis accounts, the `genutils` module must also occur after `auth` so that it can access the params from auth, IBC's `capability` module should be initialized before all other modules so that it can initialize any capabilities.
-* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](./08-genesis.md#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](../../develop/beginner/00-app-anatomy.md#constructor-function).
-* `SetOrderPreBlockers(moduleNames ...string)`: Sets the order in which the `PreBlock()` function of each module will be called before `BeginBlock()` of all modules. This function is generally called from the application's main [constructor function](../../develop/beginner/00-app-anatomy.md#constructor-function).
-* `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](../../develop/beginner/00-app-anatomy.md#constructor-function).
-* `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](../../develop/beginner/00-app-anatomy.md#constructor-function).
-* `SetOrderPrecommiters(moduleNames ...string)`: Sets the order in which the `Precommit()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](../../develop/beginner/00-app-anatomy.md#constructor-function).
-* `SetOrderPrepareCheckStaters(moduleNames ...string)`: Sets the order in which the `PrepareCheckState()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](../../develop/beginner/00-app-anatomy.md#constructor-function).
+* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](./08-genesis.md#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](../../develop/beginner/00-overview-app.md#constructor-function).
+* `SetOrderPreBlockers(moduleNames ...string)`: Sets the order in which the `PreBlock()` function of each module will be called before `BeginBlock()` of all modules. This function is generally called from the application's main [constructor function](../../develop/beginner/00-overview-app.md#constructor-function).
+* `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](../../develop/beginner/00-overview-app.md#constructor-function).
+* `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](../../develop/beginner/00-overview-app.md#constructor-function).
+* `SetOrderPrecommiters(moduleNames ...string)`: Sets the order in which the `Precommit()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](../../develop/beginner/00-overview-app.md#constructor-function).
+* `SetOrderPrepareCheckStaters(moduleNames ...string)`: Sets the order in which the `PrepareCheckState()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](../../develop/beginner/00-overview-app.md#constructor-function).
 * `SetOrderMigrations(moduleNames ...string)`: Sets the order of migrations to be run. If not set then migrations will be run with an order defined in `DefaultMigrationsOrder`.
 * `RegisterInvariants(ir sdk.InvariantRegistry)`: Registers the [invariants](./07-invariants.md) of module implementing the `HasInvariants` interface.
 * `RegisterServices(cfg Configurator)`: Registers the services of modules implementing the `HasServices` interface.