@modern-js/main-doc 2.52.0 → 2.54.0

package/docs/en/guides/topic-detail/changesets/changelog.mdx

@@ -1,238 +0,0 @@
----
-sidebar_position: 6
----
-
-# Customizing Changelog
-
-By default, Changesets will use `@changesets/cli/changelog` to generate changelog. If the default changelog cannot meet the requirements, you can customize the generation of changelog.
-
-## Customizing Changelog Content
-
-Changelog mainly includes the following two types of information:
-
-- Changelog written in the changeset.
-
-- Version change information of related packages in this version upgrade.
-
-The custom logic mainly implements two functions, `getReleaseLine` and `getDependencyReleaseLine`, which are used to define the above two types of information, respectively.
-
-### getReleaseLine
-
-#### Params
-
-- changeset
-
-```ts
-export type VersionType = 'major' | 'minor' | 'patch' | 'none';
-
-export type Release = { name: string; type: VersionType };
-
-export type Changeset = {
-  id: string; // changeset id
-  commit?: string; // changeset commit id
-  summary: string; // changeset summary content
-  releases: Array<Release>; // The name and type information of the current computed changeset upgrade package.
-};
-```
-
-- type
-
-The upgraded version type corresponding to the current package, which is of type `VersionType` mentioned above.
-
-#### Returns
-
-Changelog content.
-
-#### Default Implementation
-
-The default processing logic of `@changesets/cli/changelog` is to split the `summary` information according to the newline `\n`, add `-` as the list header before the first line, and organize other content as the supplement of the first line below the list.
-
-```ts
-async function getReleaseLine(changeset, type) {
-  const [firstLine, ...futureLines] = changeset.summary
-    .split('\n')
-    .map(l => l.trimRight());
-
-  let returnVal = `- ${
-    changeset.commit ? `${changeset.commit}: ` : ''
-  }${firstLine}`;
-
-  if (futureLines.length > 0) {
-    returnVal += `\n${futureLines.map(l => `  ${l}`).join('\n')}`;
-  }
-
-  return returnVal;
-}
-```
-
-### getDependencyReleaseLine
-
-#### Params
-
-- changesets
-
-All associated changeset information, which is an array of `getReleaseLine` changeset types.
-
-- dependenciesUpdated
-
-```ts
-type ModCompWithPackage = {
-  name: string; // Name of the dependent module
-  type: VersionType; // Upgrade type of the dependent module
-  oldVersion: string; // Current version of the dependent module
-  newVersion: string; // New version of the dependent module
-  changesets: string[]; // List of associated changeset ids
-  packageJson: PackageJSON; // Complete package.json content of the dependent module
-  dir: string; // Path (absolute path) of the dependent module
-};
-
-type DependenciesUpdated = ModCompWithPackage[];
-```
-
-#### Returns
-
-Changelog content.
-
-#### Default Implementation
-
-By default, `@changesets/cli/changelog` will display the corresponding `Updated dependencies + commit id` information of the changesets as a list. Then, based on the `dependenciesUpdated` information, it will display the package name and new version of the corresponding dependency package as a child list item of the list.
-
-```ts
-async function getDependencyReleaseLine(changesets, dependenciesUpdated) {
-  console.log('getDependencyReleaseLine', changesets, dependenciesUpdated);
-  if (dependenciesUpdated.length === 0) return '';
-
-  const changesetLinks = changesets.map(
-    changeset =>
-      `- Updated dependencies${
-        changeset.commit ? ` [${changeset.commit}]` : ''
-      }`,
-  );
-
-  const updatedDepenenciesList = dependenciesUpdated.map(
-    dependency => `  - ${dependency.name}@${dependency.newVersion}`,
-  );
-
-  return [...changesetLinks, ...updatedDepenenciesList].join('\n');
-}
-```
-
-It is displayed as follows:
-
-```markdown
-- Updated dependencies [f0438ab]
-- Updated dependencies [f0438ab]
-  - module-3@2.0.0
-  - module-1@0.2.0
-```
-
-## Configuration
-
-The `changelog` field in the changesets configuration file is used to mark the way to get changelog.
-
-This configuration can be a string, directly declaring the module name or path of the changelog module.
-
-This configuration also supports configuring arrays. The first element in the array is the module name or path of the changelog module, and the second element is the parameter value passed to the corresponding function, which will be passed as the third parameter of the `getReleaseLine` and `getDependencyReleaseLine` functions.
-
-### Configuring Relative Paths
-
-If the changelog configuration is a relative path, it is a relative path under the `.changesets` directory.
-
-For example, create the `.changeset/my-changelog-config.js` file and define the following content:
-
-```ts title=".changeset/my-changelog-config.js"
-async function getReleaseLine(changeset, type) {}
-
-async function getDependencyReleaseLine(changesets, dependenciesUpdated) {}
-
-module.exports = {
-  getReleaseLine,
-  getDependencyReleaseLine,
-};
-```
-
-Configure `changlog` as `./my-changelog-config.js`:
-
-```json title=".changesets/config.json"
-{
-  "changelog": "./my-changelog-config.js",
-   ...
-}
-```
-
-### Using Modern.js Module
-
-Customizing changelog can also be managed using the Modern.js Module to provide a common solution.
-
-#### Use `npx @modern-js/create@latest` to create a Modern.js Module.
-
-```md
-? Please select the type of project you want to create: Npm Module
-? Please fill in the project name: custom-changelog
-? Please select the programming language: TS
-? Please select the package manager: pnpm
-```
-
-#### Implement Custom Content
-
-```ts title="src/index.ts"
-export async function getReleaseLine() {}
-
-export async function getDependencyReleaseLine() {}
-```
-
-#### Publish the module to NPM
-
-#### Install the module in the root directory of the target repository, such as `custom-changelog`.
-
-#### Configure the changelog configuration of changesets as the package name.
-
-```json title=".changesets/config.json"
-{
-  "changelog": "custom-changelog",
-   ...
-}
-```
-
-### Using Monorepo Sub-Project
-
-If your current repository is Monorepo, you can directly manage it using NPM module sub-projects.
-
-#### Run `pnpm run new` to create a NPM module sub-project
-
-```bash
-? Please select the type of project you want to create: Npm Module
-? Please fill in the sub-project name: custom-changelog
-? Please fill in the sub-project directory name: custom-changelog
-? Please select the programming language: TS
-```
-
-#### Implement Custom Content
-
-```ts title="src/index.ts"
-export async function getReleaseLine() {}
-
-export async function getDependencyReleaseLine() {}
-```
-
-#### Add the sub-project module dependency, such as `custom-changelog`, to the Monorepo root directory
-
-```json title="package.json"
-{
-  "devDependencies": {
-    "custom-changelog": "workspace:*",
-    ...
-  }
-}
-```
-
-#### Configure the changelog configuration of Changesets as the package name
-
-```json title=".changesets/config.json"
-{
-  "changelog": "custom-changelog",
-   ...
-}
-```
-
-After the module is published to NPM, it can still be used like a module type for other repositories.

package/docs/en/guides/topic-detail/changesets/commit.mdx

@@ -1,269 +0,0 @@
----
-sidebar_position: 7
----
-
-# Customizing Commit Messages
-
-Changesets supports configuring `commit` to automatically submit the current changes when running the `change` and `bump` commands.
-
-The default `commit` information is provided by `@changesets/cli/commit`, and the default information format is:
-
-![change commit](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-change-commit-info.png)
-![bump commit](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-bump-commit-info.png)
-
-When the default commit information cannot meet the requirements, custom commit information is supported.
-
-## Customizing Commit Message Content
-
-Commit information is divided into two types:
-
-- Commit information automatically generated when running the `change` command.
-- Commit information automatically generated when running the `bump` command.
-
-The custom logic mainly implements two functions, `getAddMessage` and `getVersionMessage`, which are used to define the above two types of information, respectively.
-
-### getAddMessage
-
-#### Params
-
-- changeset
-
-The current changeset information created.
-
-```ts
-type Release = {
-  name: string;
-  type: VersionType;
-};
-
-type Changeset = {
-  summary: string;
-  releases: Array<Release>;
-};
-```
-
-- options
-
-Configuration information when committing.
-
-> When the commit configuration is an array, the second parameter supports passing in default configuration information, which will be used to pass this parameter.
-
-#### Returns
-
-Commit message content.
-
-#### Default Implementation
-
-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.
-
-```ts
-type SkipCI = boolean | 'add' | 'version';
-
-const getAddMessage = async (
-  changeset: Changeset,
-  options: { skipCI?: SkipCI } | null,
-) => {
-  const skipCI = options?.skipCI === 'add' || options?.skipCI === true;
-  return outdent`docs(changeset): ${changeset.summary}${
-    skipCI ? `\n\n[skip ci]\n` : ''
-  }`;
-};
-```
-
-> [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.
-
-### getVersionMessage
-
-#### Params
-
-- releasePlan
-
-```ts
-type VersionType = 'major' | 'minor' | 'patch' | 'none';
-
-type Release = {
-  name: string;
-  type: VersionType;
-};
-
-type Changeset = {
-  id: string;
-  summary: string;
-  releases: Array<Release>;
-};
-
-type ComprehensiveRelease = {
-  name: string;
-  type: VersionType;
-  oldVersion: string;
-  newVersion: string;
-  changesets: string[];
-};
-
-type PreState = {
-  mode: 'pre' | 'exit'; // Current state of pre mode
-  tag: string; // Type of pre
-  initialVersions: {
-    [pkgName: string]: string; // Package name and version information before version upgrade
-  };
-  changesets: string[]; // List of changeset ids for this upgrade
-};
-
-type ReleasePlan = {
-  changesets: Changeset[]; // List of changesets for this upgrade
-  releases: ComprehensiveRelease[]; // Information of the current upgrade, including package name, current version, upgraded version, and upgrade type
-  preState: PreState | undefined; // If it is a pre-release, provide relevant state information
-};
-```
-
-- options
-
-Configuration information when committing.
-
-> When the commit configuration is an array, the second parameter supports passing in default configuration information, which will be used to pass this parameter.
-
-#### Returns
-
-Commit message content.
-
-#### Default Implementation
-
-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.
-
-```ts
-const getVersionMessage = async (
-  releasePlan: ReleasePlan,
-  options: { skipCI?: SkipCI } | null,
-) => {
-  const skipCI = options?.skipCI === 'version' || options?.skipCI === true;
-  const publishableReleases = releasePlan.releases.filter(
-    release => release.type !== 'none',
-  );
-  const numPackagesReleased = publishableReleases.length;
-
-  const releasesLines = publishableReleases
-    .map(release => `  ${release.name}@${release.newVersion}`)
-    .join('\n');
-
-  return outdent`
-    RELEASING: Releasing ${numPackagesReleased} package(s)
-
-    Releases:
-    ${releasesLines}
-    ${skipCI ? `\n[skip ci]\n` : ''}
-`;
-};
-```
-
-## Configuration
-
-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.
-
-This configuration can be a `boolean`. When it is `true`, the default `@changesets/cli/commit` formatting commit information will be used.
-
-This configuration can be a string, directly declaring the module name or path of the commit information acquisition module.
-
-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.
-
-### Configuring Relative Paths
-
-If the commit configuration is a relative path, it is a relative path under the `.changesets` directory.
-
-For example, create the `.changeset/my-commit-config.js` file and define the following content:
-
-```js title=".changeset/my-commit-config.js"
-async function getAddMessage(changeset, options) {}
-
-async function getVersionMessage(releasePlan, options) {}
-
-module.exports = {
-  getAddMessage,
-  getVersionMessage,
-};
-```
-
-Configure `commit` as `./my-commit-config.js`:
-
-```json title=".changesets/config.json"
-{
-  "changelog": "./my-commit-config.js",
-   ...
-}
-```
-
-### Using Modern.js Module
-
-Customizing commit can also be managed using the Modern.js Module to provide a common solution.
-
-#### Use `npx @modern-js/create@latest` to create a mModern.js Module
-
-```md
-? Please select the type of project you want to create: Npm Module
-? Please fill in the project name: custom-commit
-? Please select the programming language: TS
-? Please select the package manager: pnpm
-```
-
-#### Implement Custom Content
-
-```ts title="src/index.ts"
-export async function getAddMessage() {}
-
-export async function getVersionMessage() {}
-```
-
-#### Publish the module to NPM
-
-#### Install the corresponding module in the root directory of the target repository, such as `custom-commit`
-
-#### Configure the commit configuration of changesets as the package name
-
-```json title="package.json"
-{
-  "commit": "custom-commit",
-   ...
-}
-```
-
-### Using Monorepo Sub-Project
-
-If your current repository is Monorepo, you can directly manage it using NPM module sub-projects.
-
-#### Run `pnpm run new` to create a module sub-project
-
-```bash
-? Please select the type of project you want to create: Npm Module
-? Please fill in the sub-project name: custom-commit
-? Please fill in the sub-project directory name: custom-commit
-? Please select the programming language: TS
-```
-
-#### Implement Custom Content
-
-```ts title="src/index.ts"
-export async function getAddMessage() {}
-
-export async function getVersionMessage() {}
-```
-
-#### Add the sub-project module dependency, such as `custom-commit`, to the Monorepo root directory
-
-```json title="package.json"
-{
-  "devDependencies": {
-    "custom-commit": "workspace:*",
-    ...
-  }
-}
-```
-
-#### Configure the commit configuration of Changesets as the package name
-
-```json title=".changesets/config.json"
-{
-  "commit": "custom-commit",
-   ...
-}
-```
-
-After the module is published to NPM, it can still be used like a module type for other repositories.

package/docs/en/guides/topic-detail/changesets/config.mdx

@@ -1,147 +0,0 @@
----
-sidebar_position: 5
----
-
-# Changesets Configuration
-
-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.
-
-## Introduction
-
-### commit
-
-Type: `boolean`
-
-Default: `false`
-
-When this field is configured as `true`, the code submission operation will be automatically executed when running the `change` and `bump` commands.
-
-The default commit information format is as follows:
-
-![change commit](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-change-commit-info.png)
-![bump commit](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-bump-commit-info.png)
-
-This commit information supports customization, which we will discuss in detail in the [Customizing Commit Messages](/guides/topic-detail/changesets/commit) chapter.
-
-### access
-
-Type: `restricted` | `public`
-
-Default: `restricted`
-
-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.
-
-For packages that need to configure access in the repository, `publishConfig` can be configured in `package.json`, for example:
-
-```json title=package.json
-{
-  "publishConfig": {
-    "registry": "https://registry.npmjs.org/",
-    "access": "public"
-  }
-}
-```
-
-For packages that don't need to be published, you can set `private` to `true` in `package.json` to prevent them from being published.
-
-### baseBranch
-
-Type: `string`
-
-Default: `main`
-
-Repository main branch. This configuration is used to calculate the changed packages of the current branch and classify them.
-
-### ignore
-
-Type: `string[]`
-
-Default: `[]`
-
-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.
-
-### fixed
-
-Type: `string[][]`
-
-Default: `[]`
-
-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.
-Regular expressions can be used to match package names.
-
-### linked
-
-Type: `string[][]`
-
-Default: `[]`
-
-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.
-Regular expressions can be used to match package names.
-
-### updateInternalDependencies
-
-Type: `patch` | `minor`
-
-Default: `patch`
-
-Used to declare the version number rule for updating internal dependencies.
-
-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.
-
-For example:
-
-```
-pkg-a @ version 1.0.0
-pkg-b @ version 1.0.0
-  depends on pkg-a at range `^1.0.0
-```
-
-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`.
-
-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.
-
-### changelog
-
-Type: `boolean` | `string` | `[string, unknow]`
-
-Default: `@changesets/cli/changelog`
-
-The rule for generating changelog.
-
-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.
-
-![Close changelog configuration](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-empty-changelog.png)
-
-When configured as `@changesets/cli/changelog`, the official provided changelog generation rule will be used to convert the changeset information into changelog content.
-
-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.
-
-### \_\_\_experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH
-
-Some experimental configurations.
-
-#### onlyUpdatePeerDependentsWhenOutOfRange
-
-Type: `boolean`
-
-Default: `false`
-
-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.
-
-When this configuration is set to `true`, the version will only be updated when the declared dependencies of `peerDependence` are outside the declared range.
-
-#### updateInternalDependents
-
-Type: `always` | `out-of-range`
-
-Default: `always`
-
-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.
-
-#### useCalculatedVersionForSnapshots
-
-Type: `boolean`
-
-Default: `false`
-
-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`.