You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/maintainers_guide.md
+11-7Lines changed: 11 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,9 @@ We have included `launch.json` files that store configuration for `vscode` debug
29
29
30
30
See the [Docs README](https://github.com/slackapi/node-slack-sdk/blob/main/docs/README.md) for information on how the docs site work.
31
31
32
-
The reference docs are generated on every site build, pulling from this repo's files. The site is built automatically on every release via `docs-deploy.yml`.
32
+
The reference docs for each package is independent of the others. They're generated using `typedoc` and `typedoc-plugin-markdown`. In each package's `package.json` there's a `docs` command that generates reference docs for that package based on the configuration settings found in `/package-name/typedoc.json`.
33
+
34
+
The script places the reference markdown files in `/reference/package-name`.
33
35
34
36
### 🚀 Releases
35
37
_For beta releases, see [**Beta Releases**](https://github.com/slackapi/node-slack-sdk/blob/main/.github/maintainers_guide.md#-beta-releases) section below_
@@ -50,38 +52,40 @@ Releasing can feel intimidating at first, but rest assured: if you make a mistak
50
52
51
53
4. For each package to be released, run `npm run test` to verify that tests are passing and code is free of linting errors.
52
54
53
-
5. On your new branch, bump the version(s) in `package.json` (see [Versioning and Tags](https://github.com/slackapi/node-slack-sdk/blob/main/.github/maintainers_guide.md#-versioning-and-tags))
55
+
5. Generate the reference docs for that package by running `npm run docs`.
56
+
57
+
6. On your new branch, bump the version(s) in `package.json` (see [Versioning and Tags](https://github.com/slackapi/node-slack-sdk/blob/main/.github/maintainers_guide.md#-versioning-and-tags))
54
58
55
59
- Make a single commit for the version(s) bump, following the format in: ([Example](https://github.com/slackapi/node-slack-sdk/commit/1503609d79abf035e9e21bad7360e124e4211594))
56
60
57
61
- Create a pull request for the version change ([Example](https://github.com/slackapi/node-slack-sdk/pull/1059))
58
62
59
63
- Add appropriate labels on the PR, including `release`
60
64
61
-
6. Once the PR has been approved and tests have passed, merge it into the main repository.
65
+
7. Once the PR has been approved and tests have passed, merge it into the main repository.
62
66
63
67
- Check out your local `main` branch and update it to get the latest changes: `git checkout main && git pull origin main`
- Push the new tag up to origin: `git push --tags origin`
68
72
69
-
7. Publish the release to npm
73
+
8. Publish the release to npm
70
74
- To publish, you need to be a member of the `slack Org` on npm and set up 2-Factor Auth with your passsword generator of choice. Before you can publish with npm, you must run `npm login` from the command line.
71
75
72
76
- As the final validation, within the package directory (ex: `packages/types`), run `mv package-lock.json package-lock.json.bk && rm -rf node_modules/ dist/ && npm i && npm test && npm pack` and confirm if there are `*.js`, `*.d.ts` files under the `dist` directory.
73
77
74
78
- Run `npm publish . --otp YOUR_OTP_CODE`. To generate an OTP (One Time Password), use your password generator of choice (Duo, 1Password)
75
79
76
-
8. Close GitHub Milestone(s)
80
+
9. Close GitHub Milestone(s)
77
81
78
82
- Close the relevant GitHub Milestone(s) for the release(s)
79
83
80
84
- Check the existing GitHub Milestones to see if the next minor version exists. If it doesn't, then create a GitHub Milestone for new issues to live in. Typically, you'll create a new minor version - however, if there are any bugs that need to be carried over from the current GitHub Milestone, you could make a Milestone for a patch version to reflect those issues
81
85
82
86
- Move any unfinished, open issues to the next GitHub Milestone
83
87
84
-
9. Create GitHub Release(s) with release notes
88
+
10. Create GitHub Release(s) with release notes
85
89
86
90
- From the repository, navigate to the **Releases** section and draft a new release
87
91
@@ -93,7 +97,7 @@ Releasing can feel intimidating at first, but rest assured: if you make a mistak
93
97
94
98
- Once the release notes are ready, click the "Publish Release" button to make them public
0 commit comments