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
Yarn 4 + Lerna workspaces organize sources under `packages/*`: `cli` hosts command entrypoints and generator templates, `cli-core` handles DI/prompt infrastructure, `cli-mcp` exposes MCP servers and tools, while `cli-plugin-*` packages bundle framework-specific blueprints plus their own tests. `cli-testing` provides shared harnesses, templates live in `packages/cli/templates`, artifacts land in `dist/`, VuePress + TSDoc files stay in `docs/`, and `tools/*` holds automation scripts (TypeScript references, ESLint, Vitest installers).
6
+
7
+
## Build, Test, and Development Commands
8
+
9
+
-`yarn build`: runs `monorepo build --verbose` across every workspace.
10
+
-`yarn build:references`: refreshes TS project references after renaming or adding packages.
11
+
-`yarn test`: executes the Vitest suite once; add `--coverage` for V8 reports.
12
+
-`yarn lint` / `yarn lint:fix`: applies the flat ESLint config + Prettier formatting used in CI.
13
+
-`yarn docs:serve` / `yarn docs:build`: runs `lerna run build && tsdoc` then serves or builds the VuePress site.
14
+
15
+
## Coding Style & Naming Conventions
16
+
17
+
Author TypeScript ES modules with 2-space indentation, double quotes, and trailing commas per the shared Prettier rules. Favor named exports and keep command providers in `packages/cli/src/commands/**/NameCmd.ts`, suffixing classes with `Cmd`. Tests and utilities mirror their source paths, ending in `.spec.ts` or `.integration.spec.ts`. Plugin packages follow `cli-plugin-<feature>` naming; templates underneath use kebab-case folder names. Keep import blocks sorted (enforced by `eslint-plugin-simple-import-sort`) and reserve default exports for entry aggregators such as `packages/cli/src/index.ts`.
18
+
19
+
## Testing Guidelines
20
+
21
+
Vitest powers both unit and integration coverage. Co-locate fast tests next to implementation files, while scenario-heavy suites live under `packages/*/test/**`. Use `yarn vitest packages/cli/src/commands/init/InitCmd.spec.ts` to focus a file, prefer `.integration.spec.ts` when exercising generators end-to-end, and ship PRs with `yarn test --coverage` so CI can enforce thresholds. Mock filesystem access via helpers in `cli-testing` instead of touching the real disk.
22
+
23
+
## Commit & Pull Request Guidelines
24
+
25
+
Commit messages must satisfy Conventional Commits (see `commitlint.config.js`); scope by workspace, e.g., `feat(cli-plugin-prisma): expand seed template`. Keep subjects under 200 characters and describe behavior, not implementation minutiae. Before opening a pull request, run `yarn build`, `yarn test`, and `yarn lint`, update docs/templates when behavior changes, and link the relevant issue. Summaries should highlight user-facing changes, test evidence, and screenshots or logs when generator output shifts.
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+11-6Lines changed: 11 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,13 @@
1
-
# Contributing
1
+
# Contributing
2
+
2
3
## Introduction
3
4
4
5
First, thank you for considering contributing to Ts.ED! It is people like you that make the open source community such a great community! 😊
5
6
6
7
We welcome any type of contribution, not just code. You can help with:
7
8
9
+
- Repository-specific build, testing, and PR expectations are summarized in the [Repository Guidelines](AGENTS.md); please skim them before opening a pull request.
10
+
8
11
- QA: file bug reports, the more details you can give the better (e.g. screenshots with the console open)
9
12
- Marketing: writing blog posts, how to's, printing stickers, ...
10
13
- Community: presenting the project at meetups, organizing a dedicated meetup for the local community, ...
@@ -23,15 +26,15 @@ Code review process
23
26
The bigger the pull request, the longer it will take to review and merge. Try to break down large pull requests in smaller chunks that are easier to review and merge. It is also always helpful to have some context for your pull request. What was the purpose? Why does it matter to you?
24
27
25
28
---
29
+
26
30
### WARNING
27
31
28
32
Ts.ED project uses [conventional commits](https://www.conventionalcommits.org/en/v1.0.0-beta.4/) as format commit message.
29
33
30
34
Release note and tagging version are based on the message commits.
31
35
If you don't follow the format, our CI won't be able to increment the version correctly and your feature won't be released on NPM.
32
36
33
-
To write your commit message, see [convention page here](https://www.conventionalcommits.org/en/v1.0.0-beta.4/)
34
-
---
37
+
## To write your commit message, see [convention page here](https://www.conventionalcommits.org/en/v1.0.0-beta.4/)
35
38
36
39
## Financial contributions
37
40
@@ -42,6 +45,7 @@ We also welcome financial contributions in full transparency on our open collect
42
45
If you have any questions, create an [issue](https://github.com/tsedio/tsed/issues) (protip: do a quick search first to see if someone else didn't ask the same question before!). You can also reach us at https://gitter.im/Tsed-io/community.
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [[Become a sponsor](https://opencollective.com/tsed#sponsor)]
0 commit comments