Contribution Guidelines

The wrelik-kit repository is a shared monorepo containing vendor-agnostic adapters, utilities, and configurations for the Wrelik ecosystem. It is designed as an infrastructure layer that enforces standard integrations and provides explicit boundaries between application code and third-party services.

Sources: README.md:1-7

Core Development Principles

Contributions must adhere to a strict set of architectural principles to maintain the repository's role as stable infrastructure:

• Adapter-First Architecture: Application repositories should never use vendor SDKs directly.
• Explicit Boundaries: Minimal surface area for APIs to reduce complexity.
• Infrastructure Focus: The repository is for shared logic used by at least two applications; it is not for app-specific business logic or UI components.

Sources: README.md:11-20, CONTRIBUTING.md:10-21

Architectural Workflow

The following diagram illustrates the flow from a user request through the standardized adapter layer to the third-party vendor.

Adding a New Package

When introducing a new package to the monorepo, contributors must follow a standardized initialization process to ensure consistency across the toolkit.

1. Location: Create a new subdirectory within packages/.
2. Initialization: Define a package.json using the @wrelik/ scope.
3. Dependencies: Add @wrelik/tsconfig and @wrelik/eslint-config as development dependencies.
4. Implementation: Place the source code in src/index.ts.
5. Validation: Include minimal tests for the new logic.

Sources: CONTRIBUTING.md:3-8

Package Classification

Contributors must determine if a proposed package belongs in the repository based on the following criteria:

Sources: CONTRIBUTING.md:10-15, README.md:24-51

Development Workflow and Tooling

The project utilizes pnpm for package management and turbo for task orchestration.

Enforcement of Standards

The repository enforces architectural decisions through ESLint rules. Specifically, it prevents the direct import of vendor SDKs (like @clerk/nextjs or @prisma/client) to ensure developers use the provided @wrelik wrappers.

Sources: packages/eslint-config/index.js:14-43

Versioning and Release Lifecycle

wrelik-kit uses Changesets for managing versions and changelogs. Every change to a package requires a corresponding changeset file.

Release Process

1. Development: Features are developed in branches.
2. Changeset Creation: Run pnpm changeset to define the semver bump (patch, minor, major).
3. Pull Request: Open a PR containing the code and the generated .changeset/*.md file.
4. Version PR: A "Release" GitHub Action automatically creates a "Version Packages" PR when changesets are detected on main.
5. Publishing: Merging the Version PR triggers the NPM release.

Sources: CONTRIBUTING.md:23-41, package.json:14-16

Release Flow Sequence

Conclusion

The contribution guidelines for wrelik-kit prioritize architectural discipline and vendor abstraction. By following the mandated package initialization steps, adhering to the adapter-first principle, and utilizing the changeset-based release flow, contributors help maintain a stable and predictable infrastructure layer for all Wrelik applications.