npm - @modern-js/main-doc - Versions diffs - 2.52.0 → 2.53.0 - Mend

@modern-js/main-doc 2.52.0 → 2.53.0

Files changed (60) hide show

package/docs/en/guides/topic-detail/changesets/release.mdx DELETED Viewed

@@ -1,229 +0,0 @@
----
-sidebar_position: 3
----
-# Publishing Version
-When releasing a version, we need to upgrade the version of the corresponding packages based on the changeset generated during development, and run the publish command to publish them to NPM.
-## Steps
-:::info
-The following example commands are all using pnpm. If you need to use other package managers, please replace them as needed.
-:::
-### Modern.js Module
-#### Run the bump command in the root directory
-```bash
-pnpm run bump
-```
-![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-module-bump.png)
-When running this command, changesets will automatically perform the following operations:
-- Delete all changeset files under the `.changesets` directory.
-- Upgrade the package version based on the changeset information.
-- Write changelog information to the `CHANGELOG.md` file in the root directory. The file will be automatically created if it does not exist.
-#### Confirm and submit the current changes
-```bash
-git add .
-git commit -m "release: bump package"
-```
-#### Run the release command in the root directory to publish the package to NPM
-```bash
-pnpm run release
-```
-![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-module-release.png)
-#### Push the tag to the remote repository
-```bash
-git push --follow-tags
-```
-### Monorepo
-#### Run the bmp command in the root directory
-```bash
-pnpm run bump
-```
-![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-monorepo-bump.png)
-When running this command, changesets will automatically perform the following operations:
-- Delete all changeset files under the `.changesets` directory.
-- Upgrade the version of the relevant packages based on the changeset information. In addition to the packages written in the changeset, changesets will also analyze the dependency graph of all packages in the Monorepo during running. If is required, the version will be automatically upgraded accordingly.
-- Write changelog to the `CHANGELOG.md` file in the directory of the package that needs to be upgraded. The file will be automatically created if it does not exist.
-#### Confirm and submit the current changes
-:::info
-Make sure that the automatically upgraded version meet the expected requirements. If you need to understand the version upgrade strategy, please refer to [Version Upgrade Strategy](/guides/topic-detail/changesets/release#version-upgrade-strategy).
-:::
-```bash
-git add .
-git commit -m "release: bump package"
-```
-#### Run the release command in the root directory to publish the package to NPM
-```bash
-pnpm run release
-```
-When running this command, it will sequentially determine whether the versions of all packages in the Monorepo exist on NPM. If they do not exist, the `publish` command will be run to publish them.
-:::warning
-When the dependencies between packages in the Monorepo are declared using workspace, do not directly run `npm publish` to publish the package in the corresponding subdirectory of the package. Use the `release` command instead. When publishing, the workspace declaration will be automatically removed to ensure that the NPM package is available after publishing.
-:::
-#### Push the tag to the remote repository
-```bash
-git push --follow-tags
-```
-## Parameters
-### Parameters for the `bump` command
-- `--snapshot`: Generates a timestamp-based version.
-```bash
-pnpm run bump --snapshot canary
-```
-After running, the corresponding upgraded version will become `0.0.0-canary-20220622092823`, and `canary` is the tag configured for snapshot. If not configured, it will directly generate the form of `0.0.0-20220622092823`.
-This parameter is mainly used to publish temporary test versions for testing and does not require code submission.
-- `--ignore`: Manually ignore some packages during publishing.
-For example, if you need to ignore the `module-2` package for this release:
-```bash
-pnpm run bump --ignore module-2
-```
-After running the command, the update of the `module-2` package will be ignored. Note that if there are packages that depend on `module-2`, the corresponding packages also need to be added to the `ignore` parameter, otherwise the `bump` command will fail.
-The usage for adding multiple packages is as follows:
-```bash
-pnpm run bump --ignore module-2 --ignore module-3
-```
-### Parameters for the `release` command
-- `--otp`: Uses `npm token` to publish the package.
-```bash
-pnpm run relese --otp <token>
-```
-- `--tag`: Uses a specific tag for publishing, and `latest` is used by default.
-```bash
-pnpm run release --tag <tag>
-```
-- `--ignore-scripts`: Ignores npm scripts during publishing.
-When running the `publish` command, npm will automatically trigger many commands, such as `prepare` and `prepublish`. Using this parameter can ignore the running of these commands. This parameter is only supported in Monorepo using pnpm.
-```bash
-pnpm run release --ignore-scripts
-```
-- `--no-git-checks`: Ignores checking the current branch during publishing.
-By default, when running the `release` command, it will automatically check whether the current branch is a release branch, whether there are uncommitted changes, etc. Using this parameter can ignore git-related checks.
-```bash
-pnpm run release --no-git-checks
-```
-## Version Upgrade Strategy
-### dependencies or devDependencies
-- Only upgrade the patch version of the package itself for patch version
-For example, the following scenario exists:
-There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` exists in the `dependencies` of `module-2`.
-The current changeset is the patch version upgrade of `module-1`.
-After running the `bump` command, only the patch version of `module-1` will be upgraded.
-- Upgrade the major or minor version of the package itself for major/minor version upgrades, and upgrade the patch version of the dependent packages
-For example, the following scenario exists:
-There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` exists in the `dependencies` of `module-2`.
-The current changeset is the minor version upgrade of `module-1`.
-After running the `bump` command, `module-1` will upgrade the `minor` version, and `module-2` will upgrade the `patch` version number.
-### peerDependencies
-- Upgrade the patch version of the package itself and the dependent package for patch version dependencies
-For example, the following scenario exists:
-There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` exists in the `peerDependencies` of `module-2`.
-The current changeset is the patch version upgrade of `module-1`.
-After running the `bump` command, both `module-1` and `module-2` will upgrade the patch version.
-- Upgrade the major version of the dependent package for major/minor version upgrades of the package itself
-For example, the following scenario exists:
-There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` exists in the `peerDependencies` of `module-2`.
-The current changeset is the minor version upgrade of `module-1`.
-After running the bump command, `module-1` will upgrade the `minor` version, and `module-2` will upgrade the `major` version number.
-- Modify the upgrade strategy for peerDependencies
-The upgrade strategy of `peerDependencies` can be modified by configuring `onlyUpdatePeerDependentsWhenOutOfRange`. When only the declared version type range is exceeded, the corresponding `peerDependencies` will be upgraded.
-```json
-{
-  "___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {
-    "onlyUpdatePeerDependentsWhenOutOfRange": true
-  },
-  ...
-}
-```
-For example, the following scenario exists:
-There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` exists in the `peerDependencies` of `module-2`, and the version of `module-1` is declared using `^`.
-The current changeset is the patch or minor version upgrade of `module-1`.
-After running the `bump` command, only the version of `module-1` will be upgraded.
-Note that if the package version is in the `0.x.x` range, upgrading the `minor` version is also beyond the declared version type range.

package/docs/en/guides/topic-detail/model/test-model.mdx DELETED Viewed

@@ -1,45 +0,0 @@
----
-sidebar_position: 9
-title: Test Model
----
-# Test Model
-Testing is crucial for the stability of code. Here's an example using the `countModel` from [Quick Start](/guides/topic-detail/model/quick-start) to demonstrate how to perform unit testing on a Model in Modern.js.
-To use the testing feature, you need to first enable it. In the project root directory, execute `pnpm run new` and make the following selection:
-```bash
-? Please select the operation you want to perform: Enable optional features
-? Enable optional features Enable "Unit Testing / Integration Testing" feature
-```
-This will enable testing feature support.
-Create a new file called `count.test.ts` with the following code:
-```ts
-import { createStore } from '@modern-js/runtime/testing';
-import countModel from './count';
-describe('test model', () => {
-  it('count value should plus one after add', () => {
-    const store = createStore();
-    const [state, { add }] = store.use(countModel);
-    expect(state).toEqual({ value: 1 });
-    add();
-    expect(store.use(countModel)[0]).toEqual({ value: 2 });
-  });
-});
-```
-:::info
-The [`createStore`](/apis/app/runtime/model/create-store) used here is imported from `@modern-js/runtime/testing`, which internally uses the configuration of [`runtime.state`](/configure/app/runtime/state) to create a `store`.
-:::
-In the test case, we create a new `store` to mount `countModel`, use `store.use` to get the State and Actions of `countModel`. Then, we call the `add` Action to update the state and assert the updated state value.
-Execute the `pnpm run test` command to trigger the execution of the test case.

package/docs/zh/apis/app/runtime/testing/_category_.json DELETED Viewed

@@ -1,4 +0,0 @@
-{
-  "label": "Testing",
-  "position": 11
-}

package/docs/zh/apis/app/runtime/testing/act.mdx DELETED Viewed

@@ -1,35 +0,0 @@
----
-title: act
----
-# act
-用于确保渲染、事件、数据获取等行为已经应用在 DOM 上。
-## 使用姿势
-```ts
-import { act } from '@modern-js/runtime/testing';
-```
-## 函数签名
-`act` 和 [react-dom/test-utils act 函数](https://reactjs.org/docs/testing-recipes.html#act) 是一致的。
-## 示例
-```tsx
-import ReactDOM from 'react-dom';
-import { act } from '@modern-js/runtime/testing';
-import { Foo } from '@/components/Foo';
-describe('test act', () => {
-  it('it should be foo', () => {
-    const el = document.createElement('div');
-    act(() => {
-      ReactDOM.render(<Foo />, el);
-    });
-    expect(el.innerHTML).toBe('<div>Foo</div>');
-  });
-});
-```

package/docs/zh/apis/app/runtime/testing/cleanup.mdx DELETED Viewed

@@ -1,40 +0,0 @@
----
-title: cleanup
-sidebar_position: 3
----
-# cleanup
-用于卸载掉当前已渲染的所有组件。
-## 使用姿势
-```ts
-import { cleanup } from '@modenr-js/runtime/testing';
-```
-## 函数签名
-`function cleanup(): void`
-## 示例
-:::info
-请注意，如果你使用的测试框架支持 afterEach，并且它被注入到你的测试环境中（如 mocha、Jest 和 Jasmine），**会默认在 afterEach 钩子里执行 `cleanup`**。否则，你将需要在每次测试后进行手动清理。
-:::
-例如，如果你使用[ava](https://github.com/avajs/ava)测试框架，那么你需要像这样使用 test.afterEach 钩子。
-```tsx
-import { cleanup, render } from '@modern-js/runtime/testing';
-import test from 'ava';
-test.afterEach(cleanup);
-test('renders into document', () => {
-  render(<div />);
-  // ...
-});
-// ... more tests ...
-```

package/docs/zh/apis/app/runtime/testing/render.mdx DELETED Viewed

@@ -1,71 +0,0 @@
----
-title: render
----
-# render
-用于在测试用例中渲染组件，完成测试。
-## 使用姿势
-```ts
-import { render } from '@modern-js/runtime/testing';
-```
-## 函数签名
-```ts
-type Options = {
-  container: DOMElement;
-  baseElement: DOMElement;
-  hydrate: boolean;
-  warpper: React.ComponentType<{children: ReactNode}>;
-  queries: any;
-};
-type RenderResult = {
-  {...queries}: any;
-  container: DOMElement;
-  baseElement: DOMElement;
-  debug: function;
-  rerender: function;
-  unmount: function;
-  asFragment: function;
-}
-function render(ui: React.ReactElement<any>, options: Options): RenderResult;
-```
-### 参数
-- `ui`：需要被渲染的 React 组件。
-- `options`：render 可选配置。
-  - `container`：表示组件所要挂载到的 DOM 节点，默认是会创建一个 `div` 元素，并自动添加到 `document.body` 上。这个 `div` 元素就是组件要挂载的节点。默认值是 `document.body.append(document.createElement('div'))`。
-  - `baseElement`：用于指定 `queries` 中使用到的 `basename`。如果指定了 `container`, 则默认值为 `container` 的值，否则就是 `document.body`。
-  - `hydrate`：如果设置为 `true`，则会使用 [ReactDOM.hydrate](https://zh-hans.react.dev/reference/react-dom/hydrate) 渲染组件。默认值为 `false`。
-  - `wrapper`：是一个 react 组件，可用于自定义渲染逻辑。
-  - `queries`：自定义一些自己的 `queries`。
-### 返回值
-- `{...queries}`：所有可用的 [queries](https://testing-library.com/docs/queries/about/)。
-- `container`：挂载 React 组件的 DOM 节点。
-- `baseElement`
-- `debug`
-- `rerender`：如果想测试一个已渲染的组件在其 props 更新时的一些场景，可以使用 rerender 来现实。
-- `unmount`：会卸载掉已渲染的组件。如果想测试组件卸载后的情况（如，绑定的事件是否在 unmount 阶段被卸载掉），那么这个 API 是很帮助的。
-- `asFragment`：返回当前渲染的组件的 [DocumentFragment](https://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment) 对象。可用于测试 react 事件触发后 DOM 结构的响应。
-## 示例
-```ts
-import { render } from '@modern-js/runtime/testing';
-import App from './App';
-test('renders a message', () => {
-  const { container, getByText } = render(<App />);
-  expect(getByText('Hello, world!')).toBeInTheDocument();
-  expect(container.firstChild).toMatchInlineSnapshot(`
-    <h1>Hello, World!</h1>
-  `);
-});
-```

package/docs/zh/apis/app/runtime/testing/renderApp.mdx DELETED Viewed

@@ -1,32 +0,0 @@
----
-title: renderApp
----
-# renderApp
-`render` 函数用于测试普通组件，`renderApp` 函数用于测试应用组件。
-## 使用姿势
-```ts
-import { renderApp } from '@modern-js/runtime/testing';
-```
-应用组件指包含一些 Modern.js 上下文的组件，如 App 根组件，使用了 Model 的 Container 等。对于这类组件的测试，可以使用 `renderApp` 函数，会自动按照当前 `modern.config.js` 配置，包裹上对应的上下文信息。
-## 函数签名
-`renderApp` 和 [render](./render.mdx) 完全一致。
-## 示例
-```ts
-import { renderApp } from '@modern-js/runtime/testing';
-import App from './App';
-describe('test', () => {
-  it('test App', () => {
-    const { getByText } = renderApp(<App />);
-    expect(getByText('Hello Modern!')).toBeInTheDocument();
-  });
-});
-```

package/docs/zh/configure/app/testing/_category_.json DELETED Viewed

@@ -1,4 +0,0 @@
-{
-  "label": "testing 测试",
-  "position": 10
-}

package/docs/zh/configure/app/testing/transformer.mdx DELETED Viewed

@@ -1,19 +0,0 @@
----
-title: testing.transformer
-sidebar_label: transformer
-sidebar_position: 1
----
-# transformer
-- **类型：** `'babel-jest' | 'ts-jest'`
-- **默认值：** `babel-jest`
-:::caution Caution
-请先在当前应用项目根目录使用 [new](/apis/app/commands#modern-new) 启用测试功能。
-:::
-配置执行测试时的编译工具，默认使用 `babel-jest`。可配置为 [babel-jest](https://www.npmjs.com/package/babel-jest) 或 [ts-jest](https://github.com/kulshekhar/ts-jest)。
-:::info 补充信息
-`babel-jest` 可以编译 TS 文件，但没有类型校验。如果你希望运行测试用例的时，能对 TS 类型进行校验，可以使用 `ts-jest`。
-:::

package/docs/zh/configure/app/tools/jest.mdx DELETED Viewed

@@ -1,40 +0,0 @@
----
-sidebar_label: jest
----
-# tools.jest
-- **类型：** `Object | Function`
-- **默认值：** `{}`
-:::caution 注意
-需要先通过 `pnpm run new` 启用 单元测试 功能。
-:::
-对应 [Jest](https://jestjs.io/docs/configuration) 的配置，当为 `Object` 类型时，可以配置 Jest 所支持的所有底层配置 。
-```js title=modern.config.js
-export default defineConfig({
-  tools: {
-    jest: {
-      testTimeout: 10000,
-    },
-  },
-});
-```
-值为 `Function` 类型时，默认配置作为第一个参数传入，需要返回新的 Jest 配置对象。
-```js title=modern.config.js
-export default defineConfig({
-  tools: {
-    jest: options => {
-      return {
-        ...options,
-        testTimeout: 10000,
-      };
-    },
-  },
-});
-```

package/docs/zh/guides/advanced-features/testing.mdx DELETED Viewed

@@ -1,47 +0,0 @@
----
-sidebar_position: 14
----
-# 使用 Jest 测试
-Modern.js 默认集成了 [Jest](https://jestjs.io/) 的测试能力。
-我们首先需要执行 `pnpm run new` 启用「单元测试 / 集成测试」功能：
-```bash
-? 请选择你想要的操作 启用可选功能
-? 请选择功能名称 启用「单元测试 / 集成测试」功能
-```
-执行上述命令后，`package.json` 中将会自动添加 `"test": "modern test"` 命令。
-在 `modern.config.ts` 中注册 `@modern-js/plugin-testing` 插件后即可使用测试功能：
-```ts title="modern.config.ts"
-import { testingPlugin } from '@modern-js/plugin-testing';
-export default defineConfig({
-  ...,
-  plugins: [..., testingPlugin()],
-});
-```
-## 测试文件
-Modern.js 默认识别的测试文件路径为：`<rootDir>/src/**/*.test.[jt]s?(x)` 和 `<rootDir>/tests/**/*.test.[jt]s?(x)`。
-如果你需要自定义 test 目录，可通过 [tools.jest](/configure/app/tools/jest) 进行配置。
-## 使用姿势
-Modern.js test 支持使用 [testing-library](https://testing-library.com/docs/) 相关包 API，可直接通过 `@modern-js/runtime/testing` 进行导入:
-```ts
-import { render, screen } from '@modern-js/runtime/testing';
-```
-其他 Modern.js 支持的 testing API 可参考[这里](/apis/app/runtime/testing/cleanup)。
-## transform
-Modern.js 测试默认使用 [babel-jest](https://www.npmjs.com/package/babel-jest) 进行源码编译，如果你需要使用 [ts-jest](https://github.com/kulshekhar/ts-jest)，可以通过 [testing.transform](/configure/app/testing/transformer) 进行配置。

package/docs/zh/guides/topic-detail/changesets/_category_.json DELETED Viewed

@@ -1,4 +0,0 @@
-{
-  "label": "包版本管理",
-  "position": 5
-}