chore: upgrade Docusaurus to 3.3 (#660)

i18n/en/docusaurus-plugin-content-docs/current/about/understanding/architecture.md

@@ -49,7 +49,7 @@ Therefore, it seems logical to present the desired *requirements for an ideal ar
 
 :::note
 
-Wherever it says "easy", it means "relatively easy for a wide range of developers", because it is clear that [it will not be possible to make an ideal solution for absolutely everyone](/docs/about/mission#restrictions)
+Wherever it says "easy", it means "relatively easy for a wide range of developers", because it is clear that [it will not be possible to make an ideal solution for absolutely everyone](/docs/about/mission#limitations)
 
 :::
 

i18n/en/docusaurus-plugin-content-docs/current/get-started/overview.md

@@ -99,4 +99,4 @@ It's advised to refrain from adding new large entities while refactoring or refa
 [ext-disc-api]: https://github.com/feature-sliced/documentation/discussions/66
 [ext-material-ui]: https://github.com/mui/material-ui
 [refs-examples]: /examples
-[refs-migration]: /docs/guides/migration
+[refs-migration]: /docs/guides/migration/from-legacy

i18n/en/docusaurus-plugin-content-docs/current/guides/examples/auth.mdx

@@ -71,7 +71,7 @@ The usual [Public API of the module][refs-public-api]
 
 *Largely repeats the API declaration for the layers described below*
 
-```ts title=entities/user/ui/index.ts
+```ts title="entities/user/ui/index.ts"
 export { ViewerCard } from "./card";
 export { ViewerAvatar } from "./avatar";
 ...
@@ -84,7 +84,7 @@ In redux, the [redux-ducks](https://github.com/erikras/ducks-modular-redux) appr
 
 But explicit decomposition is not required
 
-```ts title=entities/user/model/index.ts
+```ts title="entities/user/model/index.ts"
 export * as selectors from "./selectors";
 export * as events from "./events";
 export * as stores from "./stores";
@@ -97,15 +97,15 @@ The effector model will most often consist of a single file - because it is cust
 
 If the units in the model can be schematically divided into several submodels, then [you can explicitly do this](https://github.com/feature-sliced/examples/pull/1#discussion_r654841332) denote in the Public API
 
-```ts title=entities/user/model/index.ts
+```ts title="entities/user/model/index.ts"
 export * as submodel1 from "./submodel1"
 export * as submodel2 from "./submodel2"
 ...
 ```
 </TabItem>
 </Tabs>
 
-```ts title=entities/user/index.ts
+```ts title="entities/user/index.ts"
 export * from "./ui"
 export * as viewerModel from "./model";
 ```
@@ -114,7 +114,7 @@ export * as viewerModel from "./model";
 
 It may contain components that are not related to a specific page/feature, but directly to the user's entity
 
-```tsx title=entities/user/ui/card/index.tsx
+```tsx title="entities/user/ui/card/index.tsx"
 import { Card } from "shared/ui/card";
 
 // It is considered a good practice not to link ui components from entitites directly to the model
@@ -207,7 +207,7 @@ Also, other logic can be implemented here
 
 - Authorization by an external resource
 
-```tsx title=features/auth/by-oauth/ui.tsx
+```tsx title="features/auth/by-oauth/ui.tsx"
 import { viewerModel } from "entities/viewer";
 
 export const AuthByOAuth = () => {
@@ -225,7 +225,7 @@ export const AuthByOAuth = () => {
 
 - Using the user's context in features
 
-```tsx title=features/wallet/ui.tsx
+```tsx title="features/wallet/ui.tsx"
 import { viewerModel } from "entities/viewer";
 
 export const Wallet = () => {
@@ -238,7 +238,7 @@ export const Wallet = () => {
 
 - Using the viewer components
 
-```tsx title=features/header/ui.tsx
+```tsx title="features/header/ui.tsx"
 import { ViewerAvatar } from "entities/viewer";
 ...
 export const Header = () => {
@@ -289,7 +289,7 @@ export const Header = () => {
 
 - Using the viewer components and *viewer-based* features on the pages
 
-```tsx title=pages/user/ui.tsx
+```tsx title="pages/user/ui.tsx"
 import { Wallet } from "features/wallet";
 import { ViewerCard } from "entities/viewer";
 ...
@@ -309,7 +309,7 @@ export const UserPage = () => {
 
 - Using the viewer model
 
-```tsx title=pages/some/ui.tsx
+```tsx title="pages/some/ui.tsx"
 import { viewerModel } from "entities/viewer";
 ...
 export const SomePage = () => {

i18n/en/docusaurus-plugin-content-docs/current/guides/issues/routes.mdx

@@ -13,7 +13,7 @@ import WIP from '@site/src/shared/ui/wip/tmpl.mdx'
 
 Urls to pages are hardcoded in the layers below pages
 
-```tsx title=entities/post/card
+```tsx title="entities/post/card"
 
 <Card>
     <Card.Title 
@@ -43,4 +43,4 @@ Transfer to the layers below via composition/props/factories
 ## See also
 
 - [(Thread) What if I "sew up" routing in entities/features/widgets](https://t.me/feature_sliced/4389)
-- [(Thread) Why does it smear the logic of routes only in pages](https://t.me/feature_sliced/3756)
+- [(Thread) Why does it smear the logic of routes only in pages](https://t.me/feature_sliced/3756)

i18n/en/docusaurus-plugin-content-docs/current/reference/isolation/coupling-cohesion.md

@@ -88,7 +88,7 @@ Features
 
 The application, to begin with, will have one page, and the interface will be slightly modified from the first example
 
-```tsx title=page/main/ui.tsx
+```tsx title="page/main/ui.tsx"
 <List
     Header={<ConversationSwitch />}
     Items={<Messages />}
@@ -102,7 +102,7 @@ The page data model will be organized as a **composition of features and entitie
 
 > However, the implementation using factory is optional - the feature may directly depend on the lower layers.
 
-```ts title=pages/main/model.ts
+```ts title="pages/main/model.ts"
 import { userModel } from "entitites/user"
 import { conversationModel } from "entities/conversation"
 import { contactModel } from "entities/contact"

i18n/en/docusaurus-plugin-content-docs/current/reference/public-api.md

@@ -33,7 +33,7 @@ The entity structure must have a single entry point that provides a public inter
        ├── index.ts         # Entrypoint features with its public API
 ```
 
-```ts title=**/**/index.ts
+```ts title="**/**/index.ts"
 export { Form as AuthForm } from "./ui"
 export * as authFormModel from "./model"
 ```
@@ -101,12 +101,12 @@ The public API should facilitate **easy and flexible integration**
 
 - **Bad:** there will be a name collision
 
-    ```ts title=features/auth-form/index.ts
+    ```ts title="features/auth-form/index.ts"
     export { Form } from "./ui"
     export * as model from "./model"
     ```
 
-    ```ts title=features/post-form/index.ts
+    ```ts title="features/post-form/index.ts"
     export { Form } from "./ui"
     export * as model from "./model"
     ```
@@ -118,12 +118,12 @@ The public API should facilitate **easy and flexible integration**
 
 - **Good:** the collision is solved at the interface level
 
-    ```ts title=features/auth-form/index.ts
+    ```ts title="features/auth-form/index.ts"
     export { Form as AuthForm } from "./ui"
     export * as authFormModel from "./model"
     ```
 
-    ```ts title=features/post-form/index.ts
+    ```ts title="features/post-form/index.ts"
     export { Form as PostForm } from "./ui"
     export * as postFormModel from "./model"
     ```
@@ -156,32 +156,32 @@ Name collisions should be resolved at the level of the public interface, not the
 
 - **Bad:** name collisions are resolved at the implementation level
 
-    ```ts title=features/auth-form/index.ts
+    ```ts title="features/auth-form/index.ts"
     export { AuthForm } from "./ui"
     export { authFormActions, authFormReducer } from "model"
     ```
 
-    ```ts title=features/post-form/index.ts
+    ```ts title="features/post-form/index.ts"
     export { PostForm } from "./ui"
     export { postFormActions, postFormReducer } from "model"
     ```
 
 - **Good:** name collisions are resolved at the interface level
 
-    ```ts title=features/auth-form/model.ts
+    ```ts title="features/auth-form/model.ts"
     export { actions, reducer }
     ```
 
-    ```ts title=features/auth-form/index.ts
+    ```ts title="features/auth-form/index.ts"
     export { Form as AuthForm } from "./ui"
     export * as authFormModel from "./model"
     ```
 
-     ```ts title=features/post-form/model.ts
+     ```ts title="features/post-form/model.ts"
     export { actions, reducer }
     ```
 
-    ```ts title=features/post-form/index.ts
+    ```ts title="features/post-form/index.ts"
     export { Form as PostForm } from "./ui"
     export * as postFormModel from "./model"
     ```
@@ -190,7 +190,7 @@ Name collisions should be resolved at the level of the public interface, not the
 
 In JavaScript, the public interface of a module is created by re-exporting entities from inside the module in an `index` file:
 
-```ts title=**/**/index.ts
+```ts title="**/**/index.ts"
 export { Form as AuthForm } from "./ui"
 export * as authModel from "./model"
 ```

i18n/ru/docusaurus-plugin-content-docs/current/get-started/overview.md

@@ -97,6 +97,6 @@ FSD подходит для проектов и команд любого раз
 [ext-disc-api]: https://github.com/feature-sliced/documentation/discussions/66
 [ext-material-ui]: https://github.com/mui/material-ui
 [refs-examples]: /examples
-[refs-migration]: /docs/guides/migration
+[refs-migration]: /docs/guides/migration/from-legacy
 [refs-wiki-cohesion]: https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D1%8F%D0%B7%D0%BD%D0%BE%D1%81%D1%82%D1%8C_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
 [refs-wiki-coupling]: https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D1%86%D0%B5%D0%BF%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

i18n/ru/docusaurus-plugin-content-docs/current/guides/examples/auth.mdx

@@ -68,7 +68,7 @@ import WIP from '@site/src/shared/ui/wip/tmpl.mdx'
 
 *Во многом повторяет декларацию API и для описанных ниже слоев*
 
-```ts title=entities/user/ui/index.ts
+```ts title="entities/user/ui/index.ts"
 export { ViewerCard } from "./card";
 export { ViewerAvatar } from "./avatar";
 ...
@@ -81,7 +81,7 @@ export { ViewerAvatar } from "./avatar";
 
 Но явное выделение далеко не всегда обязательно
 
-```ts title=entities/user/model/index.ts
+```ts title="entities/user/model/index.ts"
 export * as selectors from "./selectors";
 export * as events from "./events";
 export * as stores from "./stores";
@@ -94,15 +94,15 @@ export * as stores from "./stores";
 
 Если же в модели юниты можно семантично разделить на несколько сабмоделей, то [можно явно это](https://github.com/feature-sliced/examples/pull/1#discussion_r654841332) обозначить в Public API
 
-```ts title=entities/user/model/index.ts
+```ts title="entities/user/model/index.ts"
 export * as submodel1 from "./submodel1"
 export * as submodel2 from "./submodel2"
 ...
 ```
 </TabItem>
 </Tabs>
 
-```ts title=entities/user/index.ts
+```ts title="entities/user/index.ts"
 export * from "./ui"
 export * as viewerModel from "./model";
 ```
@@ -111,7 +111,7 @@ export * as viewerModel from "./model";
 
 Здесь могут содержаться компоненты, относящиеся не к конкретной странице/фиче, а напрямую к сущности пользователя
 
-```tsx title=entities/user/ui/card/index.tsx
+```tsx title="entities/user/ui/card/index.tsx"
 import { Card } from "shared/ui/card";
 
 // Считается хорошей практикой - не связывать напрямую с моделью ui-компоненты из entitites
@@ -205,7 +205,7 @@ const viewer = useStore($viewer);
 
 - Авторизация по внешнему ресурсу
 
-```tsx title=features/auth/by-oauth/ui.tsx
+```tsx title="features/auth/by-oauth/ui.tsx"
 import { viewerModel } from "entities/viewer";
 
 export const AuthByOAuth = () => {
@@ -223,7 +223,7 @@ export const AuthByOAuth = () => {
 
 - Использование контекста пользователя в фичах
 
-```tsx title=features/wallet/ui.tsx
+```tsx title="features/wallet/ui.tsx"
 import { viewerModel } from "entities/viewer";
 
 export const Wallet = () => {
@@ -236,7 +236,7 @@ export const Wallet = () => {
 
 - Использование компонентов вьювера
 
-```tsx title=features/header/ui.tsx
+```tsx title="features/header/ui.tsx"
 import { ViewerAvatar } from "entities/viewer";
 ...
 export const Header = () => {
@@ -287,7 +287,7 @@ export const Header = () => {
 
 - Использование компонентов вьювера и *viewer-based* фич на страницах
 
-```tsx title=pages/user/ui.tsx
+```tsx title="pages/user/ui.tsx"
 import { Wallet } from "features/wallet";
 import { ViewerCard } from "entities/viewer";
 ...
@@ -307,7 +307,7 @@ export const UserPage = () => {
 
 - Использование модели вьювера
 
-```tsx title=pages/some/ui.tsx
+```tsx title="pages/some/ui.tsx"
 import { viewerModel } from "entities/viewer";
 ...
 export const SomePage = () => {

i18n/ru/docusaurus-plugin-content-docs/current/guides/issues/routes.mdx

@@ -13,7 +13,7 @@ import WIP from '@site/src/shared/ui/wip/tmpl.mdx'
 
 Урлы к страницам хардкодятся в слоях ниже pages
 
-```tsx title=entities/post/card
+```tsx title="entities/post/card"
 
 <Card>
     <Card.Title 

i18n/ru/docusaurus-plugin-content-docs/current/reference/isolation/coupling-cohesion.md

@@ -88,7 +88,7 @@ Features
 
 В приложении, для начала, будет одна страница, интерфейс будет основан на слегка модифицированном компоненте из первого примера
 
-```tsx title=page/main/ui.tsx
+```tsx title="page/main/ui.tsx"
 <List
     Header={<ConversationSwitch />}
     Items={<Messages />}
@@ -102,7 +102,7 @@ Features
 
 > Однако, реализация в виде фабрики необязательна - фича может зависеть от нижележащих слоев и напрямую
 
-```ts title=pages/main/model.ts
+```ts title="pages/main/model.ts"
 import { userModel } from "entitites/user"
 import { conversationModel } from "entities/conversation"
 import { contactModel } from "entities/contact"

i18n/ru/docusaurus-plugin-content-docs/current/reference/layers.mdx

@@ -30,7 +30,7 @@ pagination_next: reference/slices-segments
 
 Вы не обязаны использовать все слои в своем проекте - добавляйте только те, что приносят пользу вашему проекту.
 
-## Правило импортов для слоёв
+## Правило импортов для слоёв {#import-rule-on-layers}
 
 Слои состоят из _слайсов_ — сильно сцепленных групп модулей. Feature-Sliced Design поддерживает низкую связанность, поэтому зависимости между слайсами регулируются **правилом импортов для слоёв**: