syncpack-version-groups
$
npx mdskill add TheBushidoCollective/han/syncpack-version-groupsDefines advanced version policies and groups for monorepo dependencies using syncpack configuration.
- Helps manage dependency versions by setting bans, pins, or partitions across packages.
- Integrates with syncpack tools and uses Bash, Grep, and Glob for file operations.
- Decisions are based on user-defined filters like dependencies, types, and packages in version groups.
- Presents results through structured JSON configuration files that enforce versioning rules.
SKILL.md
.github/skills/syncpack-version-groupsView on GitHub ↗
---
name: syncpack-version-groups
user-invocable: false
description: Use when defining version policies, banning dependencies, pinning versions, or creating partitioned version groups in syncpack. Covers advanced version management patterns.
allowed-tools:
- Read
- Write
- Edit
- Bash
- Grep
- Glob
---
# Syncpack Version Groups
Version groups allow you to define sophisticated dependency version policies in your monorepo. This skill covers advanced patterns for version management.
## Version Group Structure
```js
export default {
versionGroups: [
{
label: 'Description of this group',
dependencies: ['package-name', '@scope/**'],
dependencyTypes: ['prod', 'dev'],
packages: ['apps/**'],
specifierTypes: ['exact', 'range'],
// Policy options (choose one)
preferVersion: 'highestSemver',
// pinVersion: '1.0.0',
// isBanned: true,
// isIgnored: true,
},
],
};
```
## Filter Options
### dependencies
Match specific packages by name or glob:
```js
dependencies: [
'react', // exact match
'react-*', // wildcard
'@types/**', // scoped packages
'{react,vue}', // either/or
]
```
### dependencyTypes
Filter by where dependencies appear:
```js
dependencyTypes: [
'dev', // devDependencies
'local', // workspace: protocol
'overrides', // npm overrides
'peer', // peerDependencies
'pnpmOverrides', // pnpm.overrides
'prod', // dependencies
'resolutions', // yarn resolutions
]
```
### packages
Filter by which package.json files:
```js
packages: [
'apps/**', // all apps
'packages/core', // specific package
'!packages/legacy', // exclude pattern
]
```
### specifierTypes
Filter by version specifier format:
```js
specifierTypes: [
'exact', // 1.2.3
'range', // ^1.2.3, ~1.0.0, >=2.0.0
'tag', // latest, next, canary
'url', // https://, git://
'file', // file:../path
'workspace', // workspace:*
]
```
## Version Policies
### preferVersion
Choose which version wins when mismatches exist:
```js
// Use the highest semver version found
preferVersion: 'highestSemver'
// Use the lowest semver version found
preferVersion: 'lowestSemver'
// Use whatever a specific package has
preferVersion: 'packages/core'
// Use local workspace version
preferVersion: 'local'
```
### pinVersion
Force all matches to use a specific version:
```js
{
label: 'Pin TypeScript to LTS',
dependencies: ['typescript'],
pinVersion: '5.3.3',
}
```
### isBanned
Prevent packages from being used:
```js
{
label: 'Ban deprecated packages',
dependencies: ['moment', 'request'],
isBanned: true,
}
```
### isIgnored
Exclude from version checking:
```js
{
label: 'Ignore local packages',
dependencyTypes: ['local'],
isIgnored: true,
}
```
## Common Patterns
### Monorepo Single Version Policy
```js
export default {
versionGroups: [
{
label: 'Ignore local workspace packages',
dependencyTypes: ['local'],
isIgnored: true,
},
{
label: 'Use highest version for everything else',
preferVersion: 'highestSemver',
},
],
};
```
### Framework Pinning
```js
export default {
versionGroups: [
{
label: 'Pin React version across all packages',
dependencies: ['react', 'react-dom', '@types/react', '@types/react-dom'],
pinVersion: '18.2.0',
},
],
};
```
### Different Rules for Apps vs Libraries
```js
export default {
versionGroups: [
{
label: 'Apps can have any version',
packages: ['apps/**'],
isIgnored: true,
},
{
label: 'Libraries must have consistent versions',
packages: ['packages/**'],
preferVersion: 'highestSemver',
},
],
};
```
### Ban Security Vulnerabilities
```js
export default {
versionGroups: [
{
label: 'Ban packages with known vulnerabilities',
dependencies: [
'lodash', // use lodash-es instead
'moment', // use date-fns instead
'request', // use axios/fetch instead
],
isBanned: true,
},
],
};
```
### Peer Dependency Flexibility
```js
export default {
versionGroups: [
{
label: 'Allow peer dependency flexibility',
dependencyTypes: ['peer'],
isIgnored: true,
},
{
label: 'Strict versions for prod/dev',
dependencyTypes: ['prod', 'dev'],
preferVersion: 'highestSemver',
},
],
};
```
### Scoped Package Ownership
```js
export default {
versionGroups: [
{
label: 'Core team owns @myorg/core',
dependencies: ['@myorg/core'],
preferVersion: 'packages/core',
},
{
label: 'UI team owns @myorg/ui-*',
dependencies: ['@myorg/ui-*'],
preferVersion: 'packages/ui',
},
],
};
```
## CLI Commands for Version Groups
```bash
# List all version mismatches
npx syncpack list-mismatches
# Fix version mismatches
npx syncpack fix
# Only fix specific dependencies
npx syncpack fix --dependencies react
# Only fix specific dependency types
npx syncpack fix --dependency-types prod,peer
```
## Debugging Version Groups
Use labels and run with verbose output:
```bash
npx syncpack list-mismatches --log-levels warn,error
```
## Order Matters
Version groups are evaluated in order. First matching group wins:
```js
export default {
versionGroups: [
// Specific rule first
{ dependencies: ['react'], pinVersion: '18.2.0' },
// General rule second
{ preferVersion: 'highestSemver' },
],
};
```
More from TheBushidoCollective/han
- absinthe-resolversUse when implementing GraphQL resolvers with Absinthe. Covers resolver patterns, dataloader integration, batching, and error handling.
- absinthe-schemaUse when designing GraphQL schemas with Absinthe. Covers type definitions, interfaces, unions, enums, and schema organization patterns.
- absinthe-subscriptionsUse when implementing real-time GraphQL subscriptions with Absinthe. Covers Phoenix channels, PubSub, and subscription patterns.
- act-docker-setupUse when configuring Docker environments for act, selecting runner images, managing container resources, or troubleshooting Docker-related issues with local GitHub Actions testing.
- act-local-testingUse when testing GitHub Actions workflows locally with act. Covers act CLI usage, Docker configuration, debugging workflows, and troubleshooting common issues when running workflows on your local machine.
- act-workflow-syntaxUse when creating or modifying GitHub Actions workflow files. Provides guidance on workflow syntax, triggers, jobs, steps, and expressions for creating valid GitHub Actions workflows that can be tested locally with act.
- ameba-configurationUse when configuring Ameba rules and settings for Crystal projects including .ameba.yml setup, rule management, severity levels, and code quality enforcement.
- ameba-custom-rulesUse when creating custom Ameba rules for Crystal code analysis including rule development, AST traversal, issue reporting, and rule testing.
- ameba-integrationUse when integrating Ameba into development workflows including CI/CD pipelines, pre-commit hooks, GitHub Actions, and automated code review processes.
- analyze-performanceAnalyze performance metrics and identify slow transactions in Sentry