Created `fedify test-init` CLI and fixed `fedify init` CLI with it

[2chanhaeng]

Summary

Created fedify test-init CLI and fixed fedify init CLI with it

Related Issue

• closes #461

Changes

• packages/src/cli/init
• docs/cli.md

Benefits

The fedify test-init CLI was created to make it easy for contributors who want to extend the fedify init CLI to test their changes.

Checklist

• [x] Did you add a changelog entry to the CHANGES.md?
• [x] Did you write some relevant docs about this change (if it's a new feature)?
• [x] Did you write a regression test to reproduce the bug (if it's a bug fix)?
• [ ] ~~Did you write some tests for this change (if it's a new feature)?~~
• [x] Did you run deno task test-all on your machine?

Additional Notes

fedify test-init CLI was developed solely for use in local environments. CI/CD environments were not taken into consideration.

fedify test-init CLI can't test bun, yarn, Next.js for now. The

[gemini-code-assist[bot]]

Summary of Changes

Hello @2chanhaeng, I'm Gemini Code Assist[^1]! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refines the Fedify CLI by introducing a new fedify test-init command for robust testing of project initialization configurations and enhancing the fedify init command for a more intuitive developer experience. A major architectural change involves modularizing core components, moving vocabulary runtime utilities and code generation tools into dedicated @fedify/vocab-runtime and @fedify/vocab-tools packages. This improves the overall structure and reusability of the Fedify ecosystem. Furthermore, the default ActivityPub idempotency strategy has been updated to align with standard behavior, and the CLI's underlying parsing mechanism has been upgraded to @optique/core for better maintainability. Several deprecated integration modules and an outdated example have also been removed, streamlining the project.

Highlights

• New fedify test-init CLI Command: Introduced a new CLI command, fedify test-init, designed to facilitate testing of fedify init configurations. This command creates temporary Fedify projects with various options and verifies server functionality using fedify lookup, making it easier for contributors to test framework integrations.
• Enhanced fedify init CLI Experience: The fedify init command has been updated to provide a better developer experience. It now prompts for confirmation before proceeding if the target directory is not empty, offering to move existing contents to trash. It also re-prompts for invalid or unspecified options, ensuring a smoother setup process.
• Module Separation and New Packages: Core vocabulary runtime utilities and code generation tools have been extracted from @fedify/fedify into new, dedicated packages: @fedify/vocab-runtime and @fedify/vocab-tools. This improves modularity, reduces coupling, and enables broader ecosystem compatibility for vocabulary generation.
• ActivityPub Idempotency Strategy Change: The default ActivityPub idempotency strategy has been changed from "per-origin" to "per-inbox" to align with standard ActivityPub behavior, ensuring activities are deduplicated per inbox independently.
• CLI Tooling Refactor with @optique/core: The internal command-line interface (CLI) parsing and execution logic has been refactored to utilize the @optique/core library, enhancing the robustness and maintainability of the CLI commands.
• Removal of Deprecated Integrations and Fresh Example: Several deprecated integration modules (e.g., x/cfworkers, x/denokv, x/hono, x/sveltekit) have been removed from the main @fedify/fedify package, as they have been migrated to their own dedicated packages. Additionally, the Fresh example project has been removed due to significant breaking changes in Fresh v2.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/build.yaml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

[^1]: Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

[codecov[bot]]

Codecov Report

:x: Patch coverage is 8.64198% with 74 lines in your changes missing coverage. Please review. :white_check_mark: All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
packages/cli/src/utils.ts	8.75%	73 Missing :warning:
packages/cli/src/init/action/utils.ts	0.00%	1 Missing :warning:

Files with missing lines	Coverage Δ
packages/cli/src/init/action/utils.ts	48.48% <0.00%> (ø)
packages/cli/src/utils.ts	14.19% <8.75%> (-4.49%)	:arrow_down:

:rocket: New features to boost your workflow:

• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions[bot]]

The docs for this pull request have been published:

https://555a9ee5.fedify.pages.dev

[dahlia]

Thanks for working on this PR! The fedify test-init command is a useful tool for contributors who want to test different fedify init configurations locally. However, I have some concerns about the current API design:

Issue: Internal implementation details exposed in public API

The --test-mode flag was added to the public fedify init command (packages/cli/src/init/command.ts:57-61), but this flag is only intended for internal use by fedify test-init (packages/cli/src/init/test/create.ts:84). This means:

1. Regular users will see --test-mode when they run fedify init --help
2. There's no clear reason for users to use this flag directly
3. Internal implementation details are exposed in the public API surface

Suggested alternatives

Option 1: Use environment variable instead

// Check for test mode internally without a CLI flag
const isTestMode = Deno.env.get("FEDIFY_TEST_MODE") === "1";

Then fedify test-init can set this environment variable when invoking fedify init.

Option 2: Mark as internal command Rename test-init to something that clearly indicates it's for internal/development use:

• fedify _test-init (underscore prefix)
• fedify dev:test-init (namespace prefix)

Option 3: Move to development tasks Convert this to a Deno task rather than a public CLI command:

// deno.json
{
  "tasks": {
    "test-init": "deno run -A packages/cli/src/init/test/mod.ts"
  }
}

This way it remains useful for contributors but doesn't pollute the public CLI interface.

Recommendation

I'd suggest Option 1 (environment variable) as it:

• Keeps the fedify test-init convenience for contributors
• Removes the --test-mode flag from public documentation
• Maintains clean separation between public and internal APIs

What do you think about this approach?

[github-actions[bot]]

The latest push to this pull request has been published to JSR and npm as a pre-release:

Package	Version	JSR	npm
@fedify/fedify	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/cli	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/amqp	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/cfworkers	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/denokv	2.0.0-pr.479.1922+564a1890	JSR
@fedify/elysia	2.0.0-pr.479.1922+564a1890		npm
@fedify/express	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/h3	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/hono	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/koa	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/nestjs	2.0.0-pr.479.1922+564a1890		npm
@fedify/next	2.0.0-pr.479.1922+564a1890		npm
@fedify/postgres	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/redis	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/sqlite	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/sveltekit	2.0.0-pr.479.1922+564a1890	JSR	npm
@fedify/testing	2.0.0-pr.479.1922+564a1890	JSR	npm

[dahlia]

Could you resolve conflicts?