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: CHANGELOG.md
+21Lines changed: 21 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,6 +6,27 @@ The format follows Keep a Changelog and the version numbers follow Semantic Vers
6
6
7
7
## [Unreleased]
8
8
9
+
## [0.4.0] - 2026-03-26
10
+
11
+
### Added
12
+
13
+
- Added repository hardening files and workflows: `CODEOWNERS`, Dependabot configuration, a pull-request dependency review workflow, and GitHub release artifact attestations.
14
+
- Added generated README and getting-started command guides that explain what each common command does and why it matters.
15
+
- Added a dedicated prompt reference page so users can understand what each CLI question changes and why DevForge asks it.
16
+
17
+
### Changed
18
+
19
+
- Refreshed the public README and documentation site with clearer positioning, stronger command explanations, and clearer guidance around default versus optional tooling.
20
+
- Made Husky and Commitlint opt-in defaults, while keeping ESLint and Prettier enabled as the baseline quality setup.
21
+
- Narrowed generated microfrontend strategy support to the currently implemented Vite federation flow so prompts and normalization no longer imply unsupported runtime behavior.
22
+
23
+
### Fixed
24
+
25
+
- Reworked generated microfrontend workspaces to use a federation-aware host and remote setup with stable ports, remote entry exposure, and a dev workflow that no longer races three generic Vite apps against each other.
26
+
- Improved installer UX by surfacing explicit progress steps before dependency installation and git setup begin.
27
+
- Added pnpm build-approval hints for browser-oriented scaffolds so common `esbuild` installs no longer stop at an approval warning on fresh pnpm setups.
28
+
- Updated generated Tailwind Vite scaffolds to use the current Tailwind package integration instead of writing unprocessed `@tailwind` directives without the required plugin setup.
Copy file name to clipboardExpand all lines: README.md
+80-55Lines changed: 80 additions & 55 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,77 +1,87 @@
1
1
# DevForge CLI
2
2
3
-
DevForge CLI is a production-focused, AI-native scaffolding tool for modern JavaScript and TypeScript applications. It helps teams move from project intent to a documented, installable repository with architecture guidance, AI assistant rules, testing setup, release hygiene, and baseline tooling already in place.
3
+
DevForge CLI is an AI-native scaffolding tool for JavaScript and TypeScript teams that want more than a blank starter. It turns project intent into a runnable repository with architecture guidance, starter surfaces, testing setup, AI rules, repository hygiene, and contributor docs already in place.
4
4
5
-
## Why DevForge
5
+
## Why DevForge Exists
6
6
7
-
Starting a new project usually means repeating the same setup work: choosing frameworks, wiring testing, adding linting, deciding on architecture, documenting the stack, and aligning AI assistants with team standards. DevForge turns that setup phase into a guided flow that produces a repo your team can actually build on.
7
+
Most new projects lose time before real product work even starts. Teams repeat the same setup decisions around frameworks, package managers, testing, linting, formatting, release hygiene, CI, and AI tooling. DevForge compresses that setup phase into one guided flow and outputs a repository that already explains itself.
8
8
9
9
DevForge helps you:
10
10
11
-
-reduce setup time for frontend, backend, fullstack, microfrontend, extension, and CLI projects
12
-
- avoid invalid stack combinations through built-in normalization and compatibility rules
13
-
- start with generated docs, health surfaces, project metadata, and repository hygiene from day one
14
-
-configure AI tools like Cursor, Claude, and Codex with stack-aware rule packs
15
-
-standardize project creation across teams, internal tools, client work, and experiments
11
+
-move from idea to runnable repo faster
12
+
- avoid invalid stack combinations before they land in code
13
+
- start with project docs, starter surfaces, and contributor files on day one
14
+
-standardize scaffolding across personal projects, internal tooling, and client work
15
+
-keep Cursor, Claude, and Codex aligned with the selected stack through generated rules
16
16
17
-
## What You Get
17
+
## What It Generates
18
18
19
-
- intent-driven scaffolding for landing pages, frontend apps, backend APIs, fullstack apps, microfrontends, Chrome extensions, and CLI tools
20
-
- environment-aware setup for Node.js and package manager selection
21
-
- configurable ESLint, Prettier, and Husky strictness profiles
22
-
- testing setup prompts for Vitest, Jest, Playwright, Cypress, `node`, `jsdom`, and `happy-dom`
23
-
- frontend state and data choices including Redux Toolkit, MobX, Jotai, TanStack Query, RTK Query, and more
24
-
- generated docs, AI rules, CI, contribution files, and release-ready repository hygiene
25
-
26
-
## Generated Starter Experience
27
-
28
-
DevForge does not stop at writing config files. Fresh projects include meaningful starter surfaces so the generated app explains itself:
29
-
30
-
- frontend projects render a project details page with stack information and generator metadata
31
-
- backend projects expose structured metadata from `/` and `/health`
32
-
- fullstack apps ship with a frontend surface and an API health route
33
-
- microfrontends generate a host plus remotes with role-aware starter screens
34
-
- Chrome extensions include popup, background, and content-script starter surfaces
35
-
- CLI projects expose human-readable output and machine-readable `--json` output
- generated docs, changelog-ready project metadata, and baseline repository hygiene
36
26
37
27
## Quick Start
38
28
39
-
Run without installing globally:
29
+
Run without a global install:
40
30
41
31
```bash
42
-
npx @ali-dev11/devforge@latest
32
+
npx --yes @ali-dev11/devforge@latest
43
33
```
44
34
45
35
Global install:
46
36
47
37
```bash
48
38
npm install -g @ali-dev11/devforge
49
-
create-devforge
50
-
# or
51
39
devforge
52
40
```
53
41
54
-
## Local Development
42
+
## What The CLI Asks You
55
43
56
-
```bash
57
-
npm install
58
-
npm run check
59
-
npm run build
60
-
node dist/bin/devforge.js --help
61
-
node dist/bin/devforge.js init
62
-
```
44
+
DevForge keeps core setup decisions required, and pushes the rest behind optional customization steps.
63
45
64
-
## Release History And Docs
46
+
- Always asked: project name, output directory, Node strategy, package manager, project intent, architecture when there is more than one valid choice, and stack-specific core choices like framework or backend language.
47
+
- Asked only when you opt in to customization: frontend libraries, backend capabilities, testing details, AI rule details, linting/formatting/hooks, and extra DevOps tooling.
Every prompt in DevForge exists to answer one of four questions: where the project should live, what kind of product is being created, which stack should power it, and how much team/process setup should be generated from day one.
52
+
53
+
-`Project name`: becomes the generated package or workspace name and is reused in starter screens, docs, and metadata.
54
+
-`Output directory`: tells DevForge where to write files. It is needed so the generator knows which folder to create or validate before writing.
55
+
-`Node.js version`: controls whether the scaffold follows the current LTS track, the latest available release, or a custom pinned version for stricter team environments.
56
+
-`Package manager`: chooses the lockfile, install command, and workspace behavior for the generated project.
57
+
-`What are you building?`: decides the entire downstream flow, including whether DevForge asks frontend, backend, extension, CLI, or workspace-specific questions.
58
+
-`Architecture style`: determines whether the output is a single app, a modular codebase, a monorepo, or a microfrontend workspace when that makes sense for the selected intent.
59
+
-`Template tier`: controls how much baseline setup and production-minded structure the scaffold should include.
60
+
61
+
The full prompt-by-prompt guide is here:
62
+
63
+
-[Prompt Reference](./docs/prompts.md)
64
+
65
+
## Default Versus Optional Tooling
66
+
67
+
- ESLint: enabled by default because most teams want lint feedback immediately.
68
+
- Prettier: enabled by default so formatting stays consistent across humans and AI tools.
69
+
- Husky: optional and off by default because local git hooks are team-policy dependent.
70
+
- Commitlint: optional and off by default unless you explicitly want commit-message enforcement.
71
+
- Docker and generated GitHub Actions: optional, depending on whether the project needs containerization or repo-level automation from day one.
72
+
73
+
## How DevForge Helps In Practice
74
+
75
+
- For frontend teams, it creates a visible starter surface that shows the selected stack, project metadata, and generator details.
76
+
- For backend teams, it exposes structured metadata and health endpoints so the scaffold is immediately inspectable.
77
+
- For fullstack teams, it gives you both a frontend shell and an API surface instead of only config files.
78
+
- For platform teams, it creates repeatable project conventions around docs, testing, and AI rules.
79
+
- For public packages and client work, it reduces “first week” setup drift and gives contributors a clearer starting point.
71
80
72
81
## Development Commands
73
82
74
83
```bash
84
+
npm install
75
85
npm run lint
76
86
npm run typecheck
77
87
npm run test
@@ -82,16 +92,30 @@ npm run smoke
82
92
npm run runtime:matrix -- --scenario backend-hono --scenario cli-tool
83
93
```
84
94
85
-
## Documentation
95
+
## Why These Commands Matter
86
96
97
+
-`npm install` installs local development dependencies for the DevForge repository itself.
98
+
-`npm run lint` checks repository code quality rules.
99
+
-`npm run typecheck` validates the TypeScript source without emitting build output.
100
+
-`npm run test` runs regression coverage for prompts, normalization, generator output, changelog rendering, and runtime-matrix coverage.
101
+
-`npm run build` compiles the CLI into `dist/` so the published package and smoke runs use built artifacts.
102
+
-`npm run check` is the main contributor safety command because it combines linting, typechecking, tests, and build verification.
103
+
-`npm run docs:changelog` refreshes the GitHub Pages changelog page from `CHANGELOG.md`.
104
+
-`npm run smoke` verifies a non-interactive scaffold run end to end.
105
+
-`npm run runtime:matrix -- --scenario ...` installs, builds, and verifies generated projects so the scaffold output is tested as a product, not just as source code.
- Added repository hardening files and workflows: `CODEOWNERS`, Dependabot configuration, a pull-request dependency review workflow, and GitHub release artifact attestations.
17
+
- Added generated README and getting-started command guides that explain what each common command does and why it matters.
18
+
- Added a dedicated prompt reference page so users can understand what each CLI question changes and why DevForge asks it.
19
+
20
+
### Changed
21
+
22
+
- Refreshed the public README and documentation site with clearer positioning, stronger command explanations, and clearer guidance around default versus optional tooling.
23
+
- Made Husky and Commitlint opt-in defaults, while keeping ESLint and Prettier enabled as the baseline quality setup.
24
+
- Narrowed generated microfrontend strategy support to the currently implemented Vite federation flow so prompts and normalization no longer imply unsupported runtime behavior.
25
+
26
+
### Fixed
27
+
28
+
- Reworked generated microfrontend workspaces to use a federation-aware host and remote setup with stable ports, remote entry exposure, and a dev workflow that no longer races three generic Vite apps against each other.
29
+
- Improved installer UX by surfacing explicit progress steps before dependency installation and git setup begin.
30
+
- Added pnpm build-approval hints for browser-oriented scaffolds so common `esbuild` installs no longer stop at an approval warning on fresh pnpm setups.
31
+
- Updated generated Tailwind Vite scaffolds to use the current Tailwind package integration instead of writing unprocessed `@tailwind` directives without the required plugin setup.
Copy file name to clipboardExpand all lines: docs/development.md
+30-12Lines changed: 30 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,8 +7,8 @@ title: Development
7
7
## Prerequisites
8
8
9
9
- Node.js 20+
10
-
- npm 10+ recommended
11
-
- Use Node `20.19.0+` or `22.12.0+` when running generated frontend or extension runtime scenarios locally.
10
+
- npm 10+ recommended for working on the DevForge repository
11
+
- Use Node `20.19.0+` or `22.12.0+` when running generated frontend or extension runtime scenarios locally
12
12
13
13
## Local Setup
14
14
@@ -17,23 +17,41 @@ npm install
17
17
npm run check
18
18
```
19
19
20
-
## Common Commands
20
+
## Repository Commands
21
21
22
22
```bash
23
23
npm run dev -- --help
24
-
npm run build
25
-
npm run test
26
24
npm run lint
25
+
npm run typecheck
26
+
npm run test
27
+
npm run build
28
+
npm run check
27
29
npm run docs:changelog
28
30
npm run smoke
29
31
npm run runtime:matrix -- --scenario backend-hono --scenario cli-tool
30
32
```
31
33
32
-
## Workflow
34
+
## Why Each Command Exists
35
+
36
+
-`npm run dev -- --help` lets you exercise the CLI locally without publishing a package first.
37
+
-`npm run lint` checks repository code-style and code-quality rules.
38
+
-`npm run typecheck` catches TypeScript regressions before runtime.
39
+
-`npm run test` runs focused regression tests for prompting, normalization, generator output, changelog rendering, and runtime-matrix coverage.
40
+
-`npm run build` compiles the CLI to `dist/`, which mirrors what npm users receive.
41
+
-`npm run check` is the primary contributor gate because it runs lint, types, tests, and build verification together.
42
+
-`npm run docs:changelog` keeps the GitHub Pages changelog synchronized with `CHANGELOG.md`.
43
+
-`npm run smoke` verifies a fast end-to-end scaffold run without interactive prompts.
44
+
-`npm run runtime:matrix -- --scenario ...` validates generated projects as products by installing, building, and checking runtime behavior for representative stacks.
45
+
46
+
## Working On Generated Scaffolds
47
+
48
+
- Prefer `npm run smoke` for quick CLI sanity checks.
49
+
- Use `npm run runtime:matrix` when changing templates, prompts, package-manager behavior, or generated runtime surfaces.
50
+
- If you touch microfrontend templates, validate the generated `dev` workflow, not just build output.
51
+
- If you touch docs or release notes, rerun `npm run docs:changelog`.
52
+
53
+
## Tooling Defaults
33
54
34
-
1. Make changes in `src/`.
35
-
2. Run `npm run check`.
36
-
3. Use `npm run smoke` for an end-to-end non-interactive scaffold.
37
-
4. Use `npm run runtime:matrix` to verify generated installs, builds, and runtime surfaces for representative stacks.
38
-
5. Run `npm run docs:changelog` after changelog updates so the GitHub Pages release history stays aligned.
39
-
6. Update docs when command behavior or generated output changes.
55
+
- ESLint and Prettier are default-on in generated projects because they are broad quality baselines.
56
+
- Husky and Commitlint are opt-in because local hook enforcement is not appropriate for every team or prototype.
57
+
- Generated GitHub Actions, Docker, and heavier DevOps setup remain optional to avoid forcing unnecessary tooling into every scaffold.
0 commit comments