@modern-js/main-doc 2.51.0 → 2.53.0

Sign up to get free protection for your applications and to get access to all the features.
Files changed (68) hide show
  1. package/docs/en/apis/app/runtime/web-server/unstable_middleware.mdx +30 -4
  2. package/docs/en/guides/advanced-features/web-server.mdx +4 -2
  3. package/docs/en/guides/basic-features/data/data-fetch.mdx +28 -0
  4. package/docs/en/guides/basic-features/deploy.mdx +143 -33
  5. package/docs/en/guides/basic-features/routes.mdx +2 -2
  6. package/docs/en/guides/get-started/tech-stack.mdx +0 -6
  7. package/docs/en/guides/topic-detail/framework-plugin/plugin-api.mdx +1 -1
  8. package/docs/en/guides/topic-detail/generator/create/option.md +0 -5
  9. package/docs/en/guides/topic-detail/generator/create/use.mdx +1 -10
  10. package/docs/en/guides/topic-detail/generator/new/config.md +0 -29
  11. package/docs/en/guides/topic-detail/generator/new/use.md +0 -20
  12. package/docs/zh/apis/app/runtime/web-server/unstable_middleware.mdx +30 -4
  13. package/docs/zh/guides/advanced-features/web-server.mdx +1 -1
  14. package/docs/zh/guides/basic-features/data/data-fetch.mdx +27 -2
  15. package/docs/zh/guides/basic-features/deploy.mdx +140 -36
  16. package/docs/zh/guides/basic-features/routes.mdx +2 -2
  17. package/docs/zh/guides/get-started/tech-stack.mdx +0 -6
  18. package/docs/zh/guides/topic-detail/framework-plugin/plugin-api.mdx +1 -1
  19. package/docs/zh/guides/topic-detail/generator/create/option.md +0 -5
  20. package/docs/zh/guides/topic-detail/generator/create/use.mdx +1 -10
  21. package/docs/zh/guides/topic-detail/generator/new/config.md +0 -31
  22. package/docs/zh/guides/topic-detail/generator/new/use.md +0 -20
  23. package/package.json +5 -5
  24. package/docs/en/apis/app/runtime/testing/_category_.json +0 -4
  25. package/docs/en/apis/app/runtime/testing/act.mdx +0 -35
  26. package/docs/en/apis/app/runtime/testing/cleanup.mdx +0 -40
  27. package/docs/en/apis/app/runtime/testing/render.mdx +0 -71
  28. package/docs/en/apis/app/runtime/testing/renderApp.mdx +0 -34
  29. package/docs/en/configure/app/testing/_category_.json +0 -4
  30. package/docs/en/configure/app/testing/transformer.mdx +0 -17
  31. package/docs/en/configure/app/tools/jest.mdx +0 -40
  32. package/docs/en/guides/advanced-features/testing.mdx +0 -47
  33. package/docs/en/guides/topic-detail/changesets/_category_.json +0 -4
  34. package/docs/en/guides/topic-detail/changesets/add.mdx +0 -125
  35. package/docs/en/guides/topic-detail/changesets/changelog.mdx +0 -238
  36. package/docs/en/guides/topic-detail/changesets/commit.mdx +0 -269
  37. package/docs/en/guides/topic-detail/changesets/config.mdx +0 -147
  38. package/docs/en/guides/topic-detail/changesets/github.mdx +0 -175
  39. package/docs/en/guides/topic-detail/changesets/introduce.mdx +0 -56
  40. package/docs/en/guides/topic-detail/changesets/release-note.mdx +0 -274
  41. package/docs/en/guides/topic-detail/changesets/release-pre.mdx +0 -49
  42. package/docs/en/guides/topic-detail/changesets/release.mdx +0 -229
  43. package/docs/en/guides/topic-detail/model/test-model.mdx +0 -45
  44. package/docs/zh/apis/app/runtime/testing/_category_.json +0 -4
  45. package/docs/zh/apis/app/runtime/testing/act.mdx +0 -35
  46. package/docs/zh/apis/app/runtime/testing/cleanup.mdx +0 -40
  47. package/docs/zh/apis/app/runtime/testing/render.mdx +0 -71
  48. package/docs/zh/apis/app/runtime/testing/renderApp.mdx +0 -32
  49. package/docs/zh/configure/app/testing/_category_.json +0 -4
  50. package/docs/zh/configure/app/testing/transformer.mdx +0 -19
  51. package/docs/zh/configure/app/tools/jest.mdx +0 -40
  52. package/docs/zh/guides/advanced-features/testing.mdx +0 -47
  53. package/docs/zh/guides/topic-detail/changesets/_category_.json +0 -4
  54. package/docs/zh/guides/topic-detail/changesets/add.mdx +0 -126
  55. package/docs/zh/guides/topic-detail/changesets/changelog.mdx +0 -238
  56. package/docs/zh/guides/topic-detail/changesets/commit.mdx +0 -269
  57. package/docs/zh/guides/topic-detail/changesets/config.mdx +0 -147
  58. package/docs/zh/guides/topic-detail/changesets/github.mdx +0 -175
  59. package/docs/zh/guides/topic-detail/changesets/introduce.mdx +0 -56
  60. package/docs/zh/guides/topic-detail/changesets/release-note.mdx +0 -274
  61. package/docs/zh/guides/topic-detail/changesets/release-pre.mdx +0 -50
  62. package/docs/zh/guides/topic-detail/changesets/release.mdx +0 -231
  63. package/docs/zh/guides/topic-detail/model/test-model.mdx +0 -45
  64. package/docs/zh/guides/topic-detail/monorepo/_category_.json +0 -4
  65. package/docs/zh/guides/topic-detail/monorepo/create-sub-project.mdx +0 -53
  66. package/docs/zh/guides/topic-detail/monorepo/intro.mdx +0 -14
  67. package/docs/zh/guides/topic-detail/monorepo/publish.mdx +0 -69
  68. package/docs/zh/guides/topic-detail/monorepo/sub-project-interface.mdx +0 -143
@@ -1,269 +0,0 @@
1
- ---
2
- sidebar_position: 7
3
- ---
4
-
5
- # Customizing Commit Messages
6
-
7
- Changesets supports configuring `commit` to automatically submit the current changes when running the `change` and `bump` commands.
8
-
9
- The default `commit` information is provided by `@changesets/cli/commit`, and the default information format is:
10
-
11
- ![change commit](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-change-commit-info.png)
12
- ![bump commit](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-bump-commit-info.png)
13
-
14
- When the default commit information cannot meet the requirements, custom commit information is supported.
15
-
16
- ## Customizing Commit Message Content
17
-
18
- Commit information is divided into two types:
19
-
20
- - Commit information automatically generated when running the `change` command.
21
- - Commit information automatically generated when running the `bump` command.
22
-
23
- The custom logic mainly implements two functions, `getAddMessage` and `getVersionMessage`, which are used to define the above two types of information, respectively.
24
-
25
- ### getAddMessage
26
-
27
- #### Params
28
-
29
- - changeset
30
-
31
- The current changeset information created.
32
-
33
- ```ts
34
- type Release = {
35
- name: string;
36
- type: VersionType;
37
- };
38
-
39
- type Changeset = {
40
- summary: string;
41
- releases: Array<Release>;
42
- };
43
- ```
44
-
45
- - options
46
-
47
- Configuration information when committing.
48
-
49
- > When the commit configuration is an array, the second parameter supports passing in default configuration information, which will be used to pass this parameter.
50
-
51
- #### Returns
52
-
53
- Commit message content.
54
-
55
- #### Default Implementation
56
-
57
- The default processing logic of `@changesets/cli/commit` is to start with `docs(changeset):`, and the commit information is the `summary` of the changeset, and [skip ci] information is added according to the `skipCI` parameter configuration passed in.
58
-
59
- ```ts
60
- type SkipCI = boolean | 'add' | 'version';
61
-
62
- const getAddMessage = async (
63
- changeset: Changeset,
64
- options: { skipCI?: SkipCI } | null,
65
- ) => {
66
- const skipCI = options?.skipCI === 'add' || options?.skipCI === true;
67
- return outdent`docs(changeset): ${changeset.summary}${
68
- skipCI ? `\n\n[skip ci]\n` : ''
69
- }`;
70
- };
71
- ```
72
-
73
- > [outdent](https://www.npmjs.com/package/outdent) is used to remove the leading whitespace content of the template string to make the commit information more compliant with the specification.
74
-
75
- ### getVersionMessage
76
-
77
- #### Params
78
-
79
- - releasePlan
80
-
81
- ```ts
82
- type VersionType = 'major' | 'minor' | 'patch' | 'none';
83
-
84
- type Release = {
85
- name: string;
86
- type: VersionType;
87
- };
88
-
89
- type Changeset = {
90
- id: string;
91
- summary: string;
92
- releases: Array<Release>;
93
- };
94
-
95
- type ComprehensiveRelease = {
96
- name: string;
97
- type: VersionType;
98
- oldVersion: string;
99
- newVersion: string;
100
- changesets: string[];
101
- };
102
-
103
- type PreState = {
104
- mode: 'pre' | 'exit'; // Current state of pre mode
105
- tag: string; // Type of pre
106
- initialVersions: {
107
- [pkgName: string]: string; // Package name and version information before version upgrade
108
- };
109
- changesets: string[]; // List of changeset ids for this upgrade
110
- };
111
-
112
- type ReleasePlan = {
113
- changesets: Changeset[]; // List of changesets for this upgrade
114
- releases: ComprehensiveRelease[]; // Information of the current upgrade, including package name, current version, upgraded version, and upgrade type
115
- preState: PreState | undefined; // If it is a pre-release, provide relevant state information
116
- };
117
- ```
118
-
119
- - options
120
-
121
- Configuration information when committing.
122
-
123
- > When the commit configuration is an array, the second parameter supports passing in default configuration information, which will be used to pass this parameter.
124
-
125
- #### Returns
126
-
127
- Commit message content.
128
-
129
- #### Default Implementation
130
-
131
- The default processing logic of `@changesets/cli/commit` is to first display the number of packages that need to be released, then display the names and new version of the released packages, and [skip ci] information is added according to the `skipCI` parameter configuration passed in.
132
-
133
- ```ts
134
- const getVersionMessage = async (
135
- releasePlan: ReleasePlan,
136
- options: { skipCI?: SkipCI } | null,
137
- ) => {
138
- const skipCI = options?.skipCI === 'version' || options?.skipCI === true;
139
- const publishableReleases = releasePlan.releases.filter(
140
- release => release.type !== 'none',
141
- );
142
- const numPackagesReleased = publishableReleases.length;
143
-
144
- const releasesLines = publishableReleases
145
- .map(release => ` ${release.name}@${release.newVersion}`)
146
- .join('\n');
147
-
148
- return outdent`
149
- RELEASING: Releasing ${numPackagesReleased} package(s)
150
-
151
- Releases:
152
- ${releasesLines}
153
- ${skipCI ? `\n[skip ci]\n` : ''}
154
- `;
155
- };
156
- ```
157
-
158
- ## Configuration
159
-
160
- The `commit` field in the changesets configuration file is used to mark whether to submit commit information when running the `change` and `bump` commands, and the way to obtain commit information.
161
-
162
- This configuration can be a `boolean`. When it is `true`, the default `@changesets/cli/commit` formatting commit information will be used.
163
-
164
- This configuration can be a string, directly declaring the module name or path of the commit information acquisition module.
165
-
166
- This configuration also supports configuring arrays. The first element in the array is the module name or path of the commit information acquisition module, and the second element is the parameter value passed to the corresponding function, which will be passed as the second parameter of the `getAddMessage` and `getVersionMessage` functions.
167
-
168
- ### Configuring Relative Paths
169
-
170
- If the commit configuration is a relative path, it is a relative path under the `.changesets` directory.
171
-
172
- For example, create the `.changeset/my-commit-config.js` file and define the following content:
173
-
174
- ```js title=".changeset/my-commit-config.js"
175
- async function getAddMessage(changeset, options) {}
176
-
177
- async function getVersionMessage(releasePlan, options) {}
178
-
179
- module.exports = {
180
- getAddMessage,
181
- getVersionMessage,
182
- };
183
- ```
184
-
185
- Configure `commit` as `./my-commit-config.js`:
186
-
187
- ```json title=".changesets/config.json"
188
- {
189
- "changelog": "./my-commit-config.js",
190
- ...
191
- }
192
- ```
193
-
194
- ### Using Modern.js Module
195
-
196
- Customizing commit can also be managed using the Modern.js Module to provide a common solution.
197
-
198
- #### Use `npx @modern-js/create@latest` to create a mModern.js Module
199
-
200
- ```md
201
- ? Please select the type of project you want to create: Npm Module
202
- ? Please fill in the project name: custom-commit
203
- ? Please select the programming language: TS
204
- ? Please select the package manager: pnpm
205
- ```
206
-
207
- #### Implement Custom Content
208
-
209
- ```ts title="src/index.ts"
210
- export async function getAddMessage() {}
211
-
212
- export async function getVersionMessage() {}
213
- ```
214
-
215
- #### Publish the module to NPM
216
-
217
- #### Install the corresponding module in the root directory of the target repository, such as `custom-commit`
218
-
219
- #### Configure the commit configuration of changesets as the package name
220
-
221
- ```json title="package.json"
222
- {
223
- "commit": "custom-commit",
224
- ...
225
- }
226
- ```
227
-
228
- ### Using Monorepo Sub-Project
229
-
230
- If your current repository is Monorepo, you can directly manage it using NPM module sub-projects.
231
-
232
- #### Run `pnpm run new` to create a module sub-project
233
-
234
- ```bash
235
- ? Please select the type of project you want to create: Npm Module
236
- ? Please fill in the sub-project name: custom-commit
237
- ? Please fill in the sub-project directory name: custom-commit
238
- ? Please select the programming language: TS
239
- ```
240
-
241
- #### Implement Custom Content
242
-
243
- ```ts title="src/index.ts"
244
- export async function getAddMessage() {}
245
-
246
- export async function getVersionMessage() {}
247
- ```
248
-
249
- #### Add the sub-project module dependency, such as `custom-commit`, to the Monorepo root directory
250
-
251
- ```json title="package.json"
252
- {
253
- "devDependencies": {
254
- "custom-commit": "workspace:*",
255
- ...
256
- }
257
- }
258
- ```
259
-
260
- #### Configure the commit configuration of Changesets as the package name
261
-
262
- ```json title=".changesets/config.json"
263
- {
264
- "commit": "custom-commit",
265
- ...
266
- }
267
- ```
268
-
269
- After the module is published to NPM, it can still be used like a module type for other repositories.
@@ -1,147 +0,0 @@
1
- ---
2
- sidebar_position: 5
3
- ---
4
-
5
- # Changesets Configuration
6
-
7
- When initializing a Modern.js repository, the configuration file for changesets will be initialized by default, that is, the `.changeset/config.json` file. Below, we will learn in detail what configurations are supported in this file.
8
-
9
- ## Introduction
10
-
11
- ### commit
12
-
13
- Type: `boolean`
14
-
15
- Default: `false`
16
-
17
- When this field is configured as `true`, the code submission operation will be automatically executed when running the `change` and `bump` commands.
18
-
19
- The default commit information format is as follows:
20
-
21
- ![change commit](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-change-commit-info.png)
22
- ![bump commit](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-bump-commit-info.png)
23
-
24
- This commit information supports customization, which we will discuss in detail in the [Customizing Commit Messages](/guides/topic-detail/changesets/commit) chapter.
25
-
26
- ### access
27
-
28
- Type: `restricted` | `public`
29
-
30
- Default: `restricted`
31
-
32
- Used to configure the publishing form of the current package. If configured as `restricted`, it will be published as a private package. If it is `public`, it will be published as a public scope package.
33
-
34
- For packages that need to configure access in the repository, `publishConfig` can be configured in `package.json`, for example:
35
-
36
- ```json title=package.json
37
- {
38
- "publishConfig": {
39
- "registry": "https://registry.npmjs.org/",
40
- "access": "public"
41
- }
42
- }
43
- ```
44
-
45
- For packages that don't need to be published, you can set `private` to `true` in `package.json` to prevent them from being published.
46
-
47
- ### baseBranch
48
-
49
- Type: `string`
50
-
51
- Default: `main`
52
-
53
- Repository main branch. This configuration is used to calculate the changed packages of the current branch and classify them.
54
-
55
- ### ignore
56
-
57
- Type: `string[]`
58
-
59
- Default: `[]`
60
-
61
- Used to declare packages to be ignored when running the `bump` command. The usage is consistent with the `--ignore` parameter of the `bump` command. Note that the two cannot be used at the same time.
62
-
63
- ### fixed
64
-
65
- Type: `string[][]`
66
-
67
- Default: `[]`
68
-
69
- Used to group packages in monorepos. The version of packages in the same group will be bound, and each time the `bump` command is run, a package in the same group is upgraded, others will be upgraded together.
70
- Regular expressions can be used to match package names.
71
-
72
- ### linked
73
-
74
- Type: `string[][]`
75
-
76
- Default: `[]`
77
-
78
- Similar to `fixed`, it also groups packages in monorepos, but only the packages related to the changeset declaration will be upgraded when the `bump` command is run, and the version of the changeset packages in the same group will remain consistent.
79
- Regular expressions can be used to match package names.
80
-
81
- ### updateInternalDependencies
82
-
83
- Type: `patch` | `minor`
84
-
85
- Default: `patch`
86
-
87
- Used to declare the version number rule for updating internal dependencies.
88
-
89
- When upgrading the version number by running the `bump` command, the dependency declaration using the package in the repository will be automatically updated by default. After configuring this field as `minor`, if the version number is upgraded to `patch`, the reference dependency declaration will not be updated automatically.
90
-
91
- For example:
92
-
93
- ```
94
- pkg-a @ version 1.0.0
95
- pkg-b @ version 1.0.0
96
- depends on pkg-a at range `^1.0.0
97
- ```
98
-
99
- By default, when upgrading `pkg-a` to `1.0.1`, the dependency version of `pkg-a` in `pkg-b` will be updated to `^1.0.1`.
100
-
101
- When configuring `updateInternalDependencies` as `minor`, when upgrading `pkg-a` to `1.0.1`, the dependency version of `pkg-a` in `pkg-b` will not be updated. Only when the version number of `pkg-a` is upgraded to `1.1.0` or `2.0.0`, the dependency of `pkg-a` in `pkg-b` will be updated.
102
-
103
- ### changelog
104
-
105
- Type: `boolean` | `string` | `[string, unknow]`
106
-
107
- Default: `@changesets/cli/changelog`
108
-
109
- The rule for generating changelog.
110
-
111
- When configured as `false`, only the version number will be declared in the `CHANGELOG.md` file when running the `bump` command, and no other changelog information will be declared.
112
-
113
- ![Close changelog configuration](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-empty-changelog.png)
114
-
115
- When configured as `@changesets/cli/changelog`, the official provided changelog generation rule will be used to convert the changeset information into changelog content.
116
-
117
- When configured as an array, the first parameter is a custom NPM package or path, and the second parameter is the default parameter configuration that needs to be passed in. We will explain the custom format in the subsequent [Custom Changelog](/guides/topic-detail/changesets/changelog) section.
118
-
119
- ### \_\_\_experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH
120
-
121
- Some experimental configurations.
122
-
123
- #### onlyUpdatePeerDependentsWhenOutOfRange
124
-
125
- Type: `boolean`
126
-
127
- Default: `false`
128
-
129
- Configuration for the upgrade strategy of `peerDependence` dependencies. By default, when `peerDependence` is upgraded to a `minor` or `major` version, the current package will be upgraded to a major version.
130
-
131
- When this configuration is set to `true`, the version will only be updated when the declared dependencies of `peerDependence` are outside the declared range.
132
-
133
- #### updateInternalDependents
134
-
135
- Type: `always` | `out-of-range`
136
-
137
- Default: `always`
138
-
139
- When upgrading the version number by running the `bump` command, the dependency declaration using the package in the repository will be automatically updated by default. When this parameter is set to `out-of-range`, the dependency declaration using the package in the repository will be updated only when it is outside the declared range.
140
-
141
- #### useCalculatedVersionForSnapshots
142
-
143
- Type: `boolean`
144
-
145
- Default: `false`
146
-
147
- When publishing snapshots, the version format of `0.0.0-timestamp` will be used by default to ensure that users can use pre-release versions normally. When you need to ignore the above problem and use the normal version number format, that is, the current version is `1.0.1`, and the snapshot version is expected to use `1.0.1-timestamp`, you can configure this parameter as `true`.
@@ -1,175 +0,0 @@
1
- ---
2
- sidebar_position: 9
3
- ---
4
-
5
- # Using Github related tools
6
-
7
- ## BOT
8
-
9
- On Github, changesets provide a robot to detect whether the current Pull Request has changeset, and provide a UI interface to add and modify changeset.
10
-
11
- ### Installation
12
-
13
- Click [link](https://github.com/apps/changeset-bot), select Install in the upper right corner, and confirm to complete the installation.
14
-
15
- ![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-install-bot.png)
16
-
17
- ### Configuration
18
-
19
- After successful installation, you can enter the configuration page and select the application repository according to your needs.
20
-
21
- ![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-config-bot.png)
22
-
23
- ### Usage
24
-
25
- After the configuration is completed, the robot will automatically check whether each Pull Request has added changeset and provide prompt information through reply.
26
-
27
- #### No changeset added
28
-
29
- ![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-bot-no-changeset.png)
30
-
31
- You can run `pnpm run change` in the repository to add changeset, or click the second link below to fill in changeset directly.
32
-
33
- #### Changeset added
34
-
35
- ![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-bot-exist-changeset.png)
36
-
37
- You can click the link below to modify and add new changeset.
38
-
39
- #### No need for changeset
40
-
41
- You can directly ignore the prompt information when no changeset is added, which will not cause problems with the merging of Pull Requests.
42
-
43
- ## Action
44
-
45
- ### Automatically create Release Pull Request
46
-
47
- Modern.js provides a Github Action to automatically create release Pull Request, which can automatically run bump command, update lock file and create Pull Request operation based on the selected branch.
48
-
49
- #### Usage
50
-
51
- - Create a `.github/workflows/release-pull-request.yml` file in the repository and fill in the following content:
52
-
53
- ```yaml
54
- name: Release Pull Request
55
-
56
- on:
57
- workflow_dispatch:
58
- inputs:
59
- version:
60
- type: choice
61
- description: 'Release Type(canary, beta, alpha, latest)'
62
- required: true
63
- default: 'latest'
64
- options:
65
- - canary
66
- - beta
67
- - alpha
68
- - latest
69
-
70
- jobs:
71
- release:
72
- name: Create Release Pull Request
73
- runs-on: ubuntu-latest
74
- steps:
75
- - name: Checkout Repo
76
- uses: actions/checkout@master
77
- with:
78
- # This makes Actions fetch only one branch to release
79
- fetch-depth: 100
80
-
81
- - ... # install dependencies and build repo package
82
- - name: Create Release Pull Request
83
- uses: web-infra-dev/actions@v2
84
- with:
85
- version: ${{ github.event.inputs.version }}
86
- versionNumber: 'auto'
87
- type: 'pull request'
88
- tools: 'modern'
89
- env:
90
- GITHUB_TOKEN: ${{ secrets.REPO_SCOPED_TOKEN }}
91
- NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
92
- REPOSITORY: ${{ github.repository }}
93
- REF: ${{ github.ref }}
94
- ```
95
-
96
- - After merging Workflow into the main branch, go to the Action page corresponding to the Github repository and select Release Pull Request:
97
-
98
- ![Release Pull Request Action](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/action-pull-request.png)
99
-
100
- - Select the release type of this release, and click the Run workflow button:
101
-
102
- ![Run Release Pull Request](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/action-pull-request.jpeg)
103
-
104
- - After the workflow is completed, a `Release-${version}` Pull Request will be automatically created, the related version number of `bump` changeset will be automatically updated, and the lock file will be updated. The content of Pull Request is the Release Note automatically generated by running the `gen-release-note` command.
105
-
106
- ![Release Pull Request](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/release-pull-request.jpeg)
107
-
108
- ### Automatic Release
109
-
110
- Modern.js provides a Github Action to automatically release versions, which can automatically run release command based on the selected branch and publish the package to NPM.
111
-
112
- #### Usage
113
-
114
- - Create a `.github/workflows/release.yml` file in the repository and fill in the following content:
115
-
116
- ```yaml
117
- name: Release
118
-
119
- on:
120
- workflow_dispatch:
121
- inputs:
122
- version:
123
- type: choice
124
- description: 'Release Version(canary, beta, alpha, latest)'
125
- required: true
126
- default: 'next'
127
- options:
128
- - canary
129
- - beta
130
- - alpha
131
- - latest
132
- branch:
133
- description: 'Release Branch(confirm release branch)'
134
- required: true
135
- default: 'main'
136
-
137
- jobs:
138
- release:
139
- name: Release
140
- runs-on: ubuntu-latest
141
- steps:
142
- - name: Checkout Repo
143
- uses: actions/checkout@master
144
- with:
145
- # This makes Actions fetch only one branch to release
146
- fetch-depth: 1
147
-
148
- - ... # install dependencies and build repo package
149
- - name: Release
150
- uses: web-infra-dev/actions@v2
151
- with:
152
- version: ${{ github.event.inputs.version }}
153
- branch: ${{ github.event.inputs.branch }}
154
- type: 'release'
155
- tools: 'modern'
156
- env:
157
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
158
- NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
159
- REPOSITORY: ${{ github.repository }}
160
- REF: ${{ github.ref }}
161
- ```
162
-
163
- - Configure the NPM_TOKEN of the repository:
164
-
165
- ![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/github-set-npm-token.png)
166
-
167
- - After merging Workflow into the main branch, go to the Action page corresponding to the Github repository and select Release:
168
-
169
- ![Release Action](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/release-action.png)
170
-
171
- - Select the branch name and release version type, and click the Run workflow button:
172
-
173
- ![Run Release Action](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/run-release-workflow.png)
174
-
175
- - Workflow will automatically complete the build and release to NPM process of the repository.
@@ -1,56 +0,0 @@
1
- ---
2
- sidebar_position: 1
3
- ---
4
-
5
- # Introducing Changesets
6
-
7
- Modern.js integrates [changesets](https://github.com/changesets/changesets) for package version management in Npm Module and Monorepo project.
8
-
9
- ## Features
10
-
11
- Changesets have the following features:
12
-
13
- - During development, developers need to provide the package names, the type of version upgrade (`pathch`, `minor`, `major`), and change information involved in this change.
14
-
15
- - When releasing a version, the version number of the corresponding package will be automatically upgraded based on the content of the changeset, and changelog information will be generated in the corresponding package.
16
-
17
- - In the Monorepo project, changesets will automatically generate a repository dependency graph, and only upgrade the version numbers of the changed packages and related dependent packages during upgrade.
18
-
19
- ## Initialization
20
-
21
- The Npm Module and Monorepo project created by Modern.js have already initialized changesets. The `.changeset` directory and the configuration file `.changeset/config.json` will be automatically created in the project root directory.
22
-
23
- In addition, Modern.js provides corresponding commands for changesets in its corresponding project tools `@modern-js/module-tools` and `@modern-js/monorepo-tools`, and there is no need to manually install changeset-related dependencies.
24
-
25
- The default configuration for changesets is as follows:
26
-
27
- ```json title=".changeset/config.json"
28
- {
29
- "$schema": "https://unpkg.com/@changesets/config@2.0.0/schema.json",
30
- "changelog": "@changesets/cli/changelog",
31
- "commit": false,
32
- "linked": [],
33
- "access": "restricted",
34
- "baseBranch": "main",
35
- "updateInternalDependencies": "patch",
36
- "ignore": []
37
- }
38
- ```
39
-
40
- The configuration file provides some basic configurations for generating changesets. For detailed field descriptions, please refer to [Changesets configuration](/guides/topic-detail/changesets/config).
41
-
42
- ## Commands
43
-
44
- - `change`: Creates a changeset. After running this command, a changeset file will be automatically generated in the `.changeset` directory.
45
-
46
- - `bump`: Upgrades the version of the corresponding package based on the current changeset.
47
-
48
- - `pre`: Marks entering and exiting `pre release` mode. When running the `bump` command in `pre release` mode, the version format will be `x.x.x-${pre-tag}.x`.
49
-
50
- - `release`: Publishes the package to NPM.
51
-
52
- - `status`: Views the current changeset status.
53
-
54
- - `gen-release-note`: Generates Release Note information based on the current chagneset status.
55
-
56
- For specific command-supported parameters, please refer to the corresponding chapter introduction.