|
| 1 | +# Contributing to vscode-npmx |
| 2 | + |
| 3 | +Thank you for your interest in contributing! ❤️ This document provides guidelines and instructions for contributing. |
| 4 | + |
| 5 | +> [!IMPORTANT] |
| 6 | +> Please be respectful and constructive in all interactions. We aim to maintain a welcoming environment for all contributors. |
| 7 | +> [👉 Read more](./CODE_OF_CONDUCT.md) |
| 8 | +
|
| 9 | +## Goals |
| 10 | + |
| 11 | +The goal of [vscode-npmx](https://marketplace.visualstudio.com/items?itemName=npmx-dev.vscode-npmx) is to build a useful extension around [npmx.dev](https://npmx.dev), making it easier for developers to manage npm packages within VS Code. |
| 12 | + |
| 13 | +## Table of Contents |
| 14 | + |
| 15 | +- [Getting started](#getting-started) |
| 16 | + - [Prerequisites](#prerequisites) |
| 17 | + - [Setup](#setup) |
| 18 | +- [Development workflow](#development-workflow) |
| 19 | + - [Available commands](#available-commands) |
| 20 | + - [Project structure](#project-structure) |
| 21 | +- [Code style](#code-style) |
| 22 | + - [TypeScript](#typescript) |
| 23 | + - [Import order](#import-order) |
| 24 | + - [Naming conventions](#naming-conventions) |
| 25 | +- [Testing](#testing) |
| 26 | + - [Unit tests](#unit-tests) |
| 27 | +- [Submitting changes](#submitting-changes) |
| 28 | + - [Before submitting](#before-submitting) |
| 29 | + - [Pull request process](#pull-request-process) |
| 30 | + - [Commit messages and PR titles](#commit-messages-and-pr-titles) |
| 31 | +- [Pre-commit hooks](#pre-commit-hooks) |
| 32 | +- [Using AI](#using-ai) |
| 33 | +- [Questions](#questions) |
| 34 | +- [License](#license) |
| 35 | + |
| 36 | +## Getting started |
| 37 | + |
| 38 | +### Prerequisites |
| 39 | + |
| 40 | +- [Node.js](https://nodejs.org/) (LTS version recommended) |
| 41 | +- [pnpm](https://pnpm.io/) v10.28.1 or later |
| 42 | + |
| 43 | +### Setup |
| 44 | + |
| 45 | +1. fork and clone the repository |
| 46 | +2. install dependencies: |
| 47 | + |
| 48 | + ```bash |
| 49 | + pnpm install |
| 50 | + ``` |
| 51 | + |
| 52 | +3. start the development server: |
| 53 | + |
| 54 | + ```bash |
| 55 | + pnpm dev |
| 56 | + ``` |
| 57 | + |
| 58 | +4. Press `F5` to open the VS Code debugger and start the extension in a new VS Code window. |
| 59 | + |
| 60 | +## Development workflow |
| 61 | + |
| 62 | +### Available commands |
| 63 | + |
| 64 | +```bash |
| 65 | +# Development |
| 66 | +pnpm dev # Start development server |
| 67 | +pnpm build # Production build |
| 68 | +pnpm package # Save extension as vsix file to root |
| 69 | + |
| 70 | +# Code Quality |
| 71 | +pnpm lint # Run linter (oxlint + oxfmt) |
| 72 | +pnpm lint:fix # Auto-fix lint issues |
| 73 | +pnpm typecheck # TypeScript type checking |
| 74 | + |
| 75 | +# Testing |
| 76 | +pnpm test # Run tests |
| 77 | +``` |
| 78 | + |
| 79 | +### Project structure |
| 80 | + |
| 81 | +``` |
| 82 | +playground/ # Playground for testing |
| 83 | +res/ # Assets (e.g. marketplace icon) |
| 84 | +src/ # Extension source code |
| 85 | +├── extractors/ # Extractors |
| 86 | +├── providers/ # Providers |
| 87 | +├── types/ # TypeScript types |
| 88 | +├── utils/ # Utility functions |
| 89 | +├── constants.ts # Constants |
| 90 | +├── state.ts # State management |
| 91 | +└── index.ts # Extension entry point |
| 92 | +tests/ # Tests |
| 93 | +``` |
| 94 | + |
| 95 | +## Code style |
| 96 | + |
| 97 | +When committing changes, try to keep an eye out for unintended formatting updates. These can make a pull request look noisier than it really is and slow down the review process. Sometimes IDEs automatically reformat files on save, which can unintentionally introduce extra changes. |
| 98 | + |
| 99 | +If you want to get ahead of any formatting issues, you can also run `pnpm lint:fix` before committing to fix formatting across the whole project. |
| 100 | + |
| 101 | +### TypeScript |
| 102 | + |
| 103 | +- We care about good types – never cast things to `any` 💪 |
| 104 | +- Validate rather than just assert |
| 105 | + |
| 106 | +### Import order |
| 107 | + |
| 108 | +1. Type imports first (`import type { ... }`) |
| 109 | +2. Internal aliases (`#constants`, `#utils/`, etc.) |
| 110 | +3. External packages (including `node:`) |
| 111 | +4. Relative imports (`./`, `../`) |
| 112 | +5. No blank lines between groups |
| 113 | + |
| 114 | +```typescript |
| 115 | +import type { PackageVersionsInfoWithMetadata } from 'fast-npm-meta' |
| 116 | +import { logger } from '#state' |
| 117 | +import { getVersions } from 'fast-npm-meta' |
| 118 | +import { memoize } from '../memoize' |
| 119 | +``` |
| 120 | + |
| 121 | +### Naming conventions |
| 122 | + |
| 123 | +| Type | Convention | Example | |
| 124 | +| ---------------- | -------------------- | --------------------------------------------- | |
| 125 | +| Files/Folders | kebab-case | `package-json.ts`, `pnpm-workspace-yaml.ts` | |
| 126 | +| Test files | kebab-case + `.test` | `memoize.test.ts` | |
| 127 | +| Functions | camelCase | `fetchPackage`, `formatDate` | |
| 128 | +| Constants | SCREAMING_SNAKE_CASE | `NPM_REGISTRY`, `ALLOWED_TAGS` | |
| 129 | +| Types/Interfaces | PascalCase | `NpmSearchResponse`, `Extractor`, `ValidNode` | |
| 130 | + |
| 131 | +## Testing |
| 132 | + |
| 133 | +### Unit tests |
| 134 | + |
| 135 | +Write unit tests for core functionality using Vitest: |
| 136 | + |
| 137 | +```typescript |
| 138 | +import { describe, it, expect } from 'vitest' |
| 139 | + |
| 140 | +describe('featureName', () => { |
| 141 | + it('should handle expected case', () => { |
| 142 | + expect(result).toBe(expected) |
| 143 | + }) |
| 144 | +}) |
| 145 | +``` |
| 146 | + |
| 147 | +## Submitting changes |
| 148 | + |
| 149 | +### Before submitting |
| 150 | + |
| 151 | +1. ensure your code follows the style guidelines |
| 152 | +2. run linting: `pnpm lint:fix` |
| 153 | +3. run type checking: `pnpm typecheck` |
| 154 | +4. run tests: `pnpm test` |
| 155 | +5. write or update tests for your changes |
| 156 | + |
| 157 | +### Pull request process |
| 158 | + |
| 159 | +1. create a feature branch from `main` |
| 160 | +2. make your changes with clear, descriptive commits |
| 161 | +3. push your branch and open a pull request |
| 162 | +4. ensure CI checks pass (lint, type check, tests) |
| 163 | +5. request review from maintainers |
| 164 | + |
| 165 | +### Commit messages and PR titles |
| 166 | + |
| 167 | +Write clear, concise PR titles that explain the "why" behind changes. |
| 168 | + |
| 169 | +We use [Conventional Commits](https://www.conventionalcommits.org/). Since we squash on merge, the PR title becomes the commit message in `main`, so it's important to get it right. |
| 170 | + |
| 171 | +Format: `type(scope): description` |
| 172 | + |
| 173 | +**Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert` |
| 174 | + |
| 175 | +**Scopes (optional):** `docs`, `i18n`, `deps` |
| 176 | + |
| 177 | +**Examples:** |
| 178 | + |
| 179 | +- `fix: resolve search pagination issue` |
| 180 | +- `feat: add package version comparison` |
| 181 | +- `fix(i18n): update French translations` |
| 182 | +- `chore(deps): update vite to v6` |
| 183 | + |
| 184 | +> [!NOTE] |
| 185 | +> The subject must start with a lowercase letter. Individual commit messages within your PR don't need to follow this format since they'll be squashed. |
| 186 | +
|
| 187 | +### PR descriptions |
| 188 | + |
| 189 | +If your pull request directly addresses an open issue, use the following inside your PR description. |
| 190 | + |
| 191 | +```text |
| 192 | +Resolves | Fixes | Closes: #xxx |
| 193 | +``` |
| 194 | + |
| 195 | +Replace `#xxx` with either a URL to the issue, or the number of the issue. For example: |
| 196 | + |
| 197 | +```text |
| 198 | +Fixes:#123 |
| 199 | +``` |
| 200 | + |
| 201 | +or |
| 202 | + |
| 203 | +```text |
| 204 | +Closes https://github.com/npmx-dev/vscode-npmx/issues/123 |
| 205 | +``` |
| 206 | + |
| 207 | +This provides the following benefits: |
| 208 | + |
| 209 | +- it links the pull request to the issue (the merge icon will appear in the issue), so everybody can see there is an open PR |
| 210 | +- when the pull request is merged, the linked issue is automatically closed |
| 211 | + |
| 212 | +## Pre-commit hooks |
| 213 | + |
| 214 | +The project uses `nano-staged` with `husky` to automatically lint files on commit. |
| 215 | + |
| 216 | +## Using AI |
| 217 | + |
| 218 | +You're welcome to use AI tools to help you contribute. But there are two important ground rules: |
| 219 | + |
| 220 | +### 1. Never let an LLM speak for you |
| 221 | + |
| 222 | +When you write a comment, issue, or PR description, use your own words. Grammar and spelling don't matter – real connection does. AI-generated summaries tend to be long-winded, dense, and often inaccurate. Simplicity is an art. The goal is not to sound impressive, but to communicate clearly. |
| 223 | + |
| 224 | +### 2. Never let an LLM think for you |
| 225 | + |
| 226 | +Feel free to use AI to write code, tests, or point you in the right direction. But always understand what it's written before contributing it. Take personal responsibility for your contributions. Don't say "ChatGPT says..." – tell us what _you_ think. |
| 227 | + |
| 228 | +For more context, see [Using AI in open source](https://roe.dev/blog/using-ai-in-open-source). |
| 229 | + |
| 230 | +## Questions? |
| 231 | + |
| 232 | +If you have questions or need help, feel free to open an issue for discussion or join our [Discord server](https://chat.npmx.dev). |
| 233 | + |
| 234 | +## License |
| 235 | + |
| 236 | +By contributing to vscode-npmx, you agree that your contributions will be licensed under the [MIT License](LICENSE). |
0 commit comments