@nestjs-mcp/server 0.1.0-alpha.4

package/.github/workflows/pr-branch-validation.yml

@@ -0,0 +1,78 @@
+name: PR Branch Validation
+
+on:
+  pull_request:
+    types: [opened, synchronize, reopened, edited]
+    branches: [develop, main, 'release/*']
+
+jobs:
+  validate-pr-branches:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+
+      - name: Install jq
+        run: sudo apt-get update && sudo apt-get install -y jq
+
+      - name: Validate PR source and target branches
+        run: |
+          # Get source and target branches
+          SOURCE_BRANCH="${{ github.head_ref }}"
+          TARGET_BRANCH="${{ github.base_ref }}"
+
+          echo "Validating PR from $SOURCE_BRANCH to $TARGET_BRANCH"
+
+          # Extract branch type
+          SOURCE_TYPE=$(echo $SOURCE_BRANCH | cut -d'/' -f1)
+
+          # Validate branch relationships based on workflow rules
+          if [[ "$SOURCE_TYPE" == "feature" ]] || [[ "$SOURCE_TYPE" == "bugfix" ]] || [[ "$SOURCE_TYPE" == "devfix" ]]; then
+            if [[ "$TARGET_BRANCH" != "develop" ]]; then
+              echo "ERROR: feature, bugfix, and devfix branches must target the develop branch."
+              exit 1
+            fi
+
+          elif [[ "$SOURCE_TYPE" == "hotfix" ]] || [[ "$SOURCE_TYPE" == "release" ]]; then
+            if [[ "$TARGET_BRANCH" != "main" ]]; then
+              echo "ERROR: hotfix and release branches must target the main branch."
+              echo "Note: Sync to develop will be handled automatically after merge to main."
+              exit 1
+            fi
+
+          elif [[ "$SOURCE_TYPE" == "relfix" ]]; then
+            if [[ ! "$TARGET_BRANCH" =~ ^release/ ]]; then
+              echo "ERROR: relfix branches must target a release branch."
+              exit 1
+            fi
+
+          else
+            echo "Unknown branch type: $SOURCE_TYPE"
+            exit 1
+          fi
+
+          echo "PR branch validation passed"
+
+      - name: Validate version is strictly progressive (release/hotfix to main only)
+        if: ((contains(github.head_ref, 'release/') || contains(github.head_ref, 'hotfix/')) && github.base_ref == 'main')
+        run: |
+          # Get the base and head commit SHAs
+          BASE_SHA="${{ github.event.pull_request.base.sha }}"
+          HEAD_SHA="${{ github.event.pull_request.head.sha }}"
+
+          # Fetch the base branch package.json
+          git fetch origin ${{ github.base_ref }}
+          git checkout $BASE_SHA -- package.json
+          BASE_VERSION=$(jq -r .version package.json)
+
+          # Fetch the head branch package.json
+          git checkout $HEAD_SHA -- package.json
+          HEAD_VERSION=$(jq -r .version package.json)
+
+          # Compare versions using semver
+          npx semver $HEAD_VERSION -r ">"$BASE_VERSION
+          if [ $? -ne 0 ]; then
+            echo "ERROR: Version in PR ($HEAD_VERSION) must be strictly greater than base branch ($BASE_VERSION)."
+            exit 1
+          fi
+
+          echo "Version progression validation passed."

package/.github/workflows/run-tests.yml

@@ -0,0 +1,41 @@
+name: Run Tests
+
+on:
+  pull_request:
+    branches:
+      - 'release/*'
+      - 'hotfix/*'
+      - 'develop'
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v3
+
+      - name: Setup Node
+        uses: actions/setup-node@v3
+        with:
+          node-version: '22.x'
+          registry-url: 'https://registry.npmjs.org'
+
+      - name: Install PNPM
+        uses: pnpm/action-setup@v2
+        with:
+          version: 10
+
+      - name: Install dependencies
+        run: pnpm install --frozen-lockfile
+
+      - name: Run linter
+        run: pnpm lint
+
+      - name: Type check
+        run: pnpm typecheck
+
+      - name: Run unit tests
+        run: pnpm test
+
+      - name: Run build verification
+        run: pnpm run build

package/.github/workflows/sync-main-to-develop.yml

@@ -0,0 +1,53 @@
+name: Sync Main to Develop
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  sync-branches:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+        with:
+          fetch-depth: 0 # Required to access full commit history
+
+      - name: Install GitHub CLI
+        run: sudo apt-get update && sudo apt-get install -y gh
+
+      - name: Check merge source and create sync PR
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          # Get the last commit message on main (the merge commit)
+          LAST_COMMIT_MSG=$(git log -1 --pretty=%B)
+
+          # Check if the merge was from a hotfix or release branch
+          if [[ "$LAST_COMMIT_MSG" =~ Merge\ pull\ request\ .*from\ .*hotfix/ ]] || 
+             [[ "$LAST_COMMIT_MSG" =~ Merge\ pull\ request\ .*from\ .*release/ ]]; then
+            echo "Detected merge from hotfix or release branch, syncing to develop."
+
+            # Create a temporary branch for the PR
+            SYNC_BRANCH="sync-main-to-develop-$(date +%s)"
+            git checkout -b $SYNC_BRANCH
+
+            # Attempt to merge main into develop
+            git fetch origin develop:develop
+            if git merge origin/develop --no-commit --no-ff; then
+              echo "No conflicts detected. Creating PR for automatic sync."
+            else
+              echo "Conflicts detected. PR will require manual resolution."
+            fi
+
+            git commit -am "Sync main to develop after hotfix/release merge"
+            git push origin $SYNC_BRANCH
+
+            gh pr create \
+              --base develop \
+              --head $SYNC_BRANCH \
+              --title "Auto-sync: main to develop" \
+              --body "Automated PR to sync changes from main to develop after hotfix or release merge. If this PR has conflicts, manual resolution is required."
+          else
+            echo "Push to main was not from a hotfix or release branch, no sync needed."
+          fi

package/.handbook/GIT_GUIDELINES.md

@@ -0,0 +1,250 @@
+# Git Guidelines <!-- omit in toc -->
+
+This document defines the Git workflow, branch naming conventions, commit message standards, and pull request process for the MCP Server NestJS module library. Its objective is to ensure a consistent, maintainable, and collaborative development process, while enforcing best practices and compatibility with the @modelcontextprotocol/sdk. Use this guide to understand how to contribute, manage branches, and maintain code quality in this project.
+
+## Table of Contents <!-- omit in toc -->
+
+- [Branch Structure](#branch-structure)
+- [Workflow Diagram](#workflow-diagram)
+- [Branch Naming Conventions](#branch-naming-conventions)
+- [Commit Guidelines](#commit-guidelines)
+  - [Format](#format)
+  - [Types](#types)
+  - [Examples](#examples)
+- [Pull Request Process](#pull-request-process)
+- [Handling Conflicts](#handling-conflicts)
+- [Branch Protection and Pull Request Rules](#branch-protection-and-pull-request-rules)
+- [Revert and Rebase Policy](#revert-and-rebase-policy)
+- [Automation](#automation)
+- [Automatic Sync from Main to Develop](#automatic-sync-from-main-to-develop)
+- [Special Workflow Cases](#special-workflow-cases)
+  - [Bugfixes vs Hotfixes vs Relfixes vs Devfixes](#bugfixes-vs-hotfixes-vs-relfixes-vs-devfixes)
+    - [Bugfix](#bugfix)
+    - [Hotfix](#hotfix)
+    - [Relfix](#relfix)
+    - [Devfix](#devfix)
+  - [Releases](#releases)
+  - [SemVer Versioning](#semver-versioning)
+- [Version Progression Validation](#version-progression-validation)
+
+This document outlines our Git workflow, branch naming conventions, and commit message guidelines.
+
+## Branch Structure
+
+We follow a modified GitFlow workflow with the following branches:
+
+| Branch Type             | Created From | PR Target                                                 | Purpose                                                                                                                                                                               |
+| ----------------------- | ------------ | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `main`                  | -            | - (PR to develop if conflicts after hotfix/release merge) | Stable production code. If there are conflicts during the automatic sync to develop (after a hotfix or release merge), a PR from main to develop is required for conflict resolution. |
+| `develop`               | `main`       | -                                                         | Latest changes, potentially unstable. Does not make PRs to main directly.                                                                                                             |
+| `feature/*`             | `main`       | `develop`                                                 | New features and enhancements                                                                                                                                                         |
+| `bugfix/*`              | `main`       | `develop`                                                 | Non-urgent bug fixes that can wait for the next release                                                                                                                               |
+| `hotfix/*`              | `main`       | `main`                                                    | Urgent production fixes that need immediate deployment                                                                                                                                |
+| `relfix/*`              | `release/*`  | `release/*`                                               | Bug fixes specifically for a release in preparation                                                                                                                                   |
+| `devfix/*`              | `develop`    | `develop`                                                 | Bug fixes for issues only present in develop                                                                                                                                          |
+| `release/*`             | `develop`    | `main`                                                    | Preparing a new release                                                                                                                                                               |
+| `main → develop (auto)` | `main`       | `develop`                                                 | Automatic sync after hotfix/release merge to main (if no conflicts; otherwise, manual resolution required via PR from main to develop)                                                |
+
+> Note: The PR from main to develop for conflict resolution may originate from either a hotfix or a release merge. The develop branch never makes PRs to main directly. All production releases flow through release or hotfix branches.
+
+## Workflow Diagram
+
+```
+  main        ●─────────────●───────────●───────────●
+               \             ↑          ↑          / \
+                \            |          |         /   \
+   develop       ●───●───●───●──────────●────────●     ↓
+                  ↑   ↑   ↑   ↑         ↑        ↑     ●─── hotfix/critical
+                  |   |   |   |         |        |
+  feature/x      ●───●   |   |         |        |
+                          |   |         |        |
+  feature/y              ●───●         |        |
+                              |         |        |
+  bugfix/z                   ●────●    |        |
+                                    |   |        |
+  devfix/d                  ●───────●  |        |
+                                        |        |
+  release/1.0                          ●────────●
+                                        ↑
+  relfix/r                              ●
+```
+
+## Branch Naming Conventions
+
+- `feature/issue-{id}-{short-description}`: For new features
+- `bugfix/issue-{id}-{short-description}`: For non-critical bug fixes that can wait for next release
+- `hotfix/{version-number}`: For urgent production bug fixes requiring immediate deployment
+- `relfix/issue-{id}-{short-description}`: For bug fixes specifically targeting a release in preparation
+- `devfix/issue-{id}-{short-description}`: For bug fixes only present in the develop branch
+- `release/{version-number}`: For release preparation (follows SemVer)
+
+Examples:
+
+- `feature/issue-42-user-authentication`
+- `bugfix/issue-75-broken-login`
+- `hotfix/1.2.1`
+- `relfix/issue-83-validation-error`
+- `devfix/issue-91-integration-failure`
+- `release/1.2.0`
+
+## Commit Guidelines
+
+We use conventional commits for clear and structured history.
+
+### Format
+
+```
+<type>(<scope>): <subject>
+
+<body>
+
+<footer>
+```
+
+### Types
+
+- `feat`: A new feature
+- `fix`: A bug fix
+- `docs`: Documentation changes
+- `style`: Formatting changes
+- `refactor`: Code restructuring without feature changes
+- `perf`: Performance improvements
+- `test`: Test additions or corrections
+- `chore`: Build process or tool changes
+
+### Examples
+
+```
+feat(auth): add user login functionality
+
+Implement JWT-based authentication with refresh tokens.
+
+Closes #24
+```
+
+```
+fix(api): correct response status codes
+
+Change HTTP status from 200 to 201 for resource creation endpoints.
+
+Resolves #56
+```
+
+## Pull Request Process
+
+1. Create a branch from `main` using the appropriate naming convention
+2. Make your changes and commit them following the commit guidelines
+3. Pull the latest changes from the target branch
+4. Push your branch and create a PR to the appropriate target branch
+5. Request at least one reviewer
+6. Address any feedback from code reviews
+7. Once approved, the PR will be merged by a maintainer
+
+## Handling Conflicts
+
+If conflicts arise when merging:
+
+1. Pull the latest changes from the target branch
+2. Resolve conflicts locally
+3. Commit the resolved conflicts
+4. Push the changes to your branch
+
+## Branch Protection and Pull Request Rules
+
+- Only `main`, `develop`, and `release/*` branches accept pull requests. PRs to any other branch are not permitted.
+- The branches `main`, `develop`, and all `release/*` branches **must be protected** against direct push and force push. Only merges via pull request are allowed.
+- All other branches (e.g., `feature/*`, `bugfix/*`, `devfix/*`, `hotfix/*`, `relfix/*`) can receive updates via direct push.
+- This ensures the stability and integrity of the main development and release branches, while allowing flexibility in feature and fix branches.
+
+## Revert and Rebase Policy
+
+<!-- TODO: Define and document the policy for revert, squash, and rebase operations on protected branches. For now, follow standard Git best practices and avoid force pushes on protected branches. -->
+
+## Automation
+
+All possible validations and checks (linting, tests, version progression, branch naming, etc.) are automated via CI/CD workflows. Manual steps should be minimized and clearly documented if required.
+
+## Automatic Sync from Main to Develop
+
+After a `hotfix/*` or `release/*` branch is merged into `main`, an automated process will create a PR to sync `main` into `develop`. If there are no conflicts, this PR can be merged automatically. If conflicts are detected, manual resolution is required before merging.
+
+## Special Workflow Cases
+
+### Bugfixes vs Hotfixes vs Relfixes vs Devfixes
+
+We use different branch types for different kinds of fixes:
+
+#### Bugfix
+
+For non-urgent issues that can wait for the next regular release:
+
+1. Create a `bugfix/` branch from `main`
+2. Fix the issue and commit changes
+3. Create a PR to `develop`
+4. Changes will go to production with the next release cycle
+
+#### Hotfix
+
+For urgent production issues requiring immediate deployment:
+
+1. Create a `hotfix/` branch from `main`
+2. Fix the issue and commit changes
+3. Create a PR to `main`
+4. After approval, merge to `main`
+5. An automated PR will sync `main` to `develop` (manual conflict resolution may be required)
+6. Deploy to production immediately after merging to `main`
+
+#### Relfix
+
+For issues found during release preparation:
+
+1. Create a `relfix/` branch from the specific `release/*` branch
+2. Fix the issue and commit changes
+3. Create a PR targeted to the same `release/*` branch
+4. These changes will be included when the release is merged to `main`
+
+#### Devfix
+
+For issues only present in the develop branch:
+
+1. Create a `devfix/` branch from `develop`
+2. Fix the issue and commit changes
+3. Create a PR to `develop`
+4. These fixes prevent unstable code from propagating further
+
+### Releases
+
+To prepare a new release (using SemVer):
+
+1. Create a `release/` branch from `develop` (e.g., `release/1.2.0`)
+2. Only `relfix/` branches can be merged into this branch
+3. When ready, create a PR from `release/*` to `main`
+4. After approval, merge to `main`
+5. An automated PR will sync `main` to `develop` (manual conflict resolution may be required)
+6. Tag the release in `main` with the version number
+
+### SemVer Versioning
+
+We follow Semantic Versioning (SemVer) for our releases:
+
+- `MAJOR.MINOR.PATCH` (e.g., `1.2.3`)
+- `MAJOR`: Breaking changes
+- `MINOR`: New features, non-breaking
+- `PATCH`: Hotfixes and critical bug fixes
+
+Examples:
+
+- `1.0.0`: Initial release
+- `1.1.0`: New feature added
+- `1.1.1`: Hotfix for a critical issue
+- `2.0.0`: Breaking changes
+
+## Version Progression Validation
+
+For pull requests from `release/*` or `hotfix/*` branches targeting `main`, the version in the PR **must be strictly greater than** the version currently in `main`. This is enforced automatically by CI:
+
+- The PR will be rejected if the version is equal to or less than the current version in `main`.
+- This ensures that all production releases are progressive and prevents accidental downgrades or duplicate versions.
+- This rule does not apply to other branch types or targets.
+
+> **Tip:** Always bump the version as the first step in your release or hotfix branch.

package/.handbook/PACKAGE_VERSIONING.md

@@ -0,0 +1,140 @@
+# Package Versioning Guidelines <!-- omit in toc -->
+
+This document describes the versioning policy and release process for all packages in the MCP Server NestJS module library. Its objective is to ensure clear, progressive, and predictable versioning for all releases, maintain compatibility with the @modelcontextprotocol/sdk, and provide guidance for stable and pre-release workflows. Use this guide to understand how to version, tag, and publish packages in this project.
+
+## Table of Contents <!-- omit in toc -->
+
+- [Overview](#overview)
+- [Version Format](#version-format)
+- [Pre-release Identifiers](#pre-release-identifiers)
+- [Tagging and Publishing](#tagging-and-publishing)
+- [Progressive Versioning](#progressive-versioning)
+- [Version Progression Validation](#version-progression-validation)
+- [Branching and Release Flow](#branching-and-release-flow)
+- [Release Flow](#release-flow)
+- [Automation](#automation)
+- [Best Practices](#best-practices)
+- [Publication Policy](#publication-policy)
+
+## Overview
+
+This document defines the versioning strategy for all packages in this repository. The goal is to ensure clear, progressive, and predictable versioning for all releases, including pre-releases and stable versions.
+
+## Version Format
+
+We follow [Semantic Versioning 2.0.0](https://semver.org/) as the baseline:
+
+```
+MAJOR.MINOR.PATCH[-PRERELEASE]
+```
+
+- **MAJOR**: Incompatible API changes
+- **MINOR**: Backwards-compatible functionality
+- **PATCH**: Backwards-compatible bug fixes
+- **PRERELEASE**: Optional, for alpha/beta/rc versions
+
+## Pre-release Identifiers
+
+Pre-release versions are denoted by a hyphen and a label after the patch number:
+
+- `-alpha`: Early preview, unstable, not feature-complete
+- `-beta`: Feature-complete, but may contain known issues
+- `-rc`: Release candidate, stable unless critical bugs are found
+
+**Examples:**
+
+- `1.2.0-alpha.1`
+- `1.2.0-beta.2`
+- `1.2.0-rc.1`
+- `1.2.0` (final release)
+
+## Tagging and Publishing
+
+The version field in `package.json` (package version) must strictly follow the format: `X.Y.Z` or `X.Y.Z-prerelease` (e.g., `1.2.3`, `1.2.3-beta.1`). The version must never include a `v` prefix.
+
+- **Stable releases**: package version as `X.Y.Z`.
+- **Pre-releases**: package version as `X.Y.Z-prerelease.N` (e.g., `1.2.3-beta.1`).
+
+## Progressive Versioning
+
+- **All new versions MUST be strictly greater than previous versions.**
+- **Never publish a version that is equal to or less than an existing version.**
+- This ensures consumers always receive the latest, most appropriate version and avoids confusion or accidental downgrades.
+
+## Version Progression Validation
+
+All new versions MUST be strictly greater than previous versions. This is enforced automatically by CI/CD:
+
+- For pull requests from `release/*` or `hotfix/*` branches targeting `main`, the workflow checks that the version in the PR is strictly greater than the version in `main`.
+- If the version is not progressive, the PR will be rejected and must be corrected before merging.
+- This prevents accidental downgrades or duplicate versions in production.
+
+## Branching and Release Flow
+
+- **Feature, bugfix, and devfix branches**: Merge into `develop` only.
+- **Release and hotfix branches**: Merge into `main` only.
+- **Relfix branches**: Merge into a `release/*` branch only.
+- **Version numbers must always increase** with each release, regardless of branch.
+
+## Release Flow
+
+The complete release process is as follows:
+
+1. Prepare a `release/*` or `hotfix/*` branch with the new version in `package.json`.
+2. Create a PR to `main`. The CI will validate version progression and run tests.
+3. Once merged, the CI workflow will create a tag on `main`.
+4. The publish workflow will build and publish the package to NPM, assigning the correct NPM tag.
+5. An automated PR will sync `main` to `develop` to keep branches aligned.
+
+> Always ensure the version is bumped before creating the PR to `main`.
+
+## Automation
+
+- CI/CD workflows will:
+  - Validate that new versions are strictly progressive.
+  - Tag releases according to the pre-release identifier.
+  - Prevent publishing if the version is not greater than the previous.
+
+## Best Practices
+
+- Bump the version as soon as a change is made that warrants it.
+- Use pre-release identifiers for unstable or preview releases.
+- Only remove the pre-release identifier (`-alpha`, `-beta`, `-rc`) when the release is considered stable.
+- Document breaking changes and version bumps in the changelog.
+
+## Publication Policy
+
+This project follows [Semantic Versioning 2.0.0](https://semver.org/). All releases must:
+
+- Use strictly increasing version numbers (no downgrades or duplicates)
+- Use pre-release identifiers (`-alpha`, `-beta`, `-rc`) for unstable or preview releases
+- Only remove the pre-release identifier when the release is considered stable
+- Document breaking changes and version bumps in the changelog
+
+### Branching and Release Flow
+
+- Only `release/*` and `fix/*` branches are allowed for publishing
+- Final releases are only allowed from `release/*` branches
+- Pre-releases (alpha, beta, rc) are allowed from `release/*` and `fix/*` branches
+- All other branches must merge into `develop` or follow the project's branching model
+
+### Pre-release Identifiers
+
+- `-alpha`: Early preview, unstable, not feature-complete
+- `-beta`: Feature-complete, but may contain known issues
+- `-rc`: Release candidate, stable unless critical bugs are found
+
+### Tagging and Publishing
+
+- The version in `package.json` must match the intended release type and follow semver
+- The correct NPM tag and access must be used for each release type (see project scripts)
+- Always increment the version before publishing
+
+### Automation
+
+- CI/CD workflows must enforce version progression and correct tagging
+- Publishing must be blocked if the version is not strictly greater than the previous
+
+---
+
+**For implementation details and scripts, see the project README or scripts directory.**

package/.handbook/STACK.md

@@ -0,0 +1,75 @@
+# Tech Stack <!-- omit in toc -->
+
+This document provides an overview of the core technologies, tools, and configurations used in the MCP Server NestJS module library. Its objective is to clarify the project's technical foundation, ensure consistency across development environments, and help contributors understand the stack requirements for building, testing, and maintaining modules compatible with the @modelcontextprotocol/sdk.
+
+# Table of Contents <!-- omit in toc -->
+
+- [Framework](#framework)
+- [Language \& Transpilation](#language--transpilation)
+- [Package Management](#package-management)
+- [Linting](#linting)
+- [Code Formatter](#code-formatter)
+- [Testing](#testing)
+- [Build](#build)
+- [Logger](#logger)
+- [Documentation](#documentation)
+- [Environment Management](#environment-management)
+- [CI/CD](#cicd)
+- [Other](#other)
+
+This project is built primarily with **NestJS** as the main framework. All modules, services, and controllers are designed following NestJS best practices and conventions.
+
+The stack and tooling are organized by category, with the primary technology for each area explicitly listed:
+
+## Framework
+
+- **NestJS**: Main application framework for building scalable server-side applications
+
+## Language & Transpilation
+
+- **TypeScript**: Main language for all source code
+
+## Package Management
+
+- **pnpm**: For dependency management and scripts
+- **npm**: Only for package publishing
+
+## Linting
+
+- **ESLint**: Code linting (see `eslint.config.mjs`)
+
+## Code Formatter
+
+- **Prettier**: Code formatting (if `.prettierrc` is present)
+
+## Testing
+
+- **Jest**: Unit and end-to-end testing
+
+## Build
+
+- **TypeScript Compiler (tsc)**: Build process (see `tsconfig.json` and `tsconfig.build.json`)
+
+## Logger
+
+- **NestJS Logger**: Default logger for application and modules
+- **Custom Logger**: `mcp-logger.service.ts` for registry-specific logging
+
+## Documentation
+
+- **Swagger**: (If present) For API documentation via decorators
+- **Typedoc**: (If present) For code documentation
+
+## Environment Management
+
+- **dotenv**: (If present) For environment variable management
+
+## CI/CD
+
+- **GitHub Actions**: For continuous integration and deployment workflows
+
+## Other
+
+- **@modelcontextprotocol/sdk**: Core dependency for MCP Server compatibility
+
+> All tools must be used in the versions specified in the workflows and configuration files to ensure compatibility and reproducibility.

package/.prettierrc

@@ -0,0 +1,4 @@
+{
+  "singleQuote": true,
+  "trailingComma": "all"
+}