- What is a feature-based architecture?
- How can I add a feature?
- How can I add a feature description?
- How can I add an owner?
- How can I add a decision?
- How can I add a test coverage report?
- What is the technical debt of a feature?
- How can I generate codeowners file?
- I'm getting "GLIBC_2.38 not found" error on Linux, how do I fix it?
Feature-based architecture is a software development approach that organizes code and folders around features or business capabilities rather than technical layers (like components, services, or utils). It is similar to domain-driven development (DDD) but more recursive and more structured. Each feature lives in its own self-contained folder with everything it needs. It promotes modularity, maintainability, and scalability by breaking down complex systems into smaller, more manageable components.
This approach is not meant to replace other architecture design like hexagonal architecture but rather complement it. It is an approach easier to understand for beginners. It can also be shared with product managers, designers and stakeholders.
To add a new feature to the system, follow these steps:
- Create a folder
featureswhere you want in your source code directory. It can be in a subdirectory. - Inside the
featuresdirectory, create a folder with the name of the first business feature likebusiness-feature-name. It can use snake_case, camelCase, or kebab-case naming conventions. - The feature will automatically be detected and displayed in the web interface
To add a new feature description to the system, follow these steps:
- In the feature folder, create a new README.md file
- In this README.md file, provide a detailed description of the feature, including its purpose, functionality, and any relevant technical details.
- In the feature README, add a property
ownerin the frontmatter of the README.md file.
To add a new feature description to the system, follow these steps:
- In the feature folder, create a new README.md file
- In this README.md file, provide a detailed description of the feature, including its purpose, functionality, and any relevant technical details.
Do you see the message "No decisions available"? You can add one by following these steps:
- Navigate to the feature you want to add a decision to
- In the feature's directory, locate or create a
__docs__/decisions/folder or.docs/decisions/folder - Create a new Markdown file with a descriptive name (e.g.,
use-typescript.md) - Structure your decision document with the following sections:
- Title: Clear, concise description of the decision
- Status: Current status (proposed, accepted, rejected, deprecated, superseded)
- Context: Background information and the problem being solved
- Decision: The actual decision made
- Consequences: Expected positive and negative outcomes
The decision will automatically appear in the web interface under the feature's decisions section.
This decision template is inspired by the MADR initiative.
Do you see the message "No test coverage reports available"?
Generate a test coverage report by running your tests with the --coverage flag. For example, if you're using Jest, you can run npx jest --coverage.
Ensure the report is generated in the folder coverage or .coverage.
The CLI automatically searches for coverage reports in multiple locations:
base_path/.coverageandbase_path/coverage(path provided as first argument)current_dir/.coverageandcurrent_dir/coverage(path the executable runs)project_dir/.coverageandproject_dir/coverage(if--project-diris provided)
If your project uses a different directory structure or naming convention for coverage reports, you can specify the directory using the --coverage-dir flag. For example, if your coverage report is located in reports/coverage, you can run features-cli --coverage-dir reports/coverage.
The supported report formats are LCOV and Cobertura.
Right now the CLI only detects the TODOs in the code. It does not detect other types of technical debt such as code smells or performance issues.
Feel free to suggest new ways to detect technical debt.
Generate or update a CODEOWNERS file based on feature ownership:
# Generate CODEOWNERS in current directory
features ./src --generate-codeowners
# Generate CODEOWNERS in project directory with proper relative paths
features ./src --generate-codeowners --project-dir ./
# Can be combined with other commands
features ./src --generate-codeowners --build --project-dir ./The generated CODEOWNERS file will have a managed section between markers:
# ==== GENERATED BY FEATURES-CLI ====
/src/features/feature-1 @team1
/src/features/feature-2 @team2
# ==== END SECTION GENERATED BY FEATURES-CLI ====
Any content outside these markers is preserved when regenerating.
This error occurs when the Linux binary was built with a newer version of GLIBC than what's available on your system. There are several solutions:
The musl builds are statically linked and don't depend on GLIBC at all, making them the most compatible option:
# For x64 (64-bit Intel/AMD) systems
npm install -g @features-cli/feature-cli-linux-x64-musl
# For ARM64 systems
npm install -g @features-cli/feature-cli-linux-arm64-musl
# Note: npx features-cli automatically detects and uses musl on musl-based systems
npx features-cli@latest /path/to/project --serve
# Or download the musl binary directly from GitHub releases
# Look for files: features-linux-x64-musl or features-linux-arm64-muslIf you have Rust installed, you can build directly from source which will use your system's GLIBC:
cargo install features-clinpx features-cli@latest /path/to/project --serveIf possible, update your Linux distribution to a newer version that includes GLIBC 2.38 or higher. This is typically available on:
- Ubuntu 24.04 or later
- Debian 13 (Trixie) or later
- Fedora 39 or later