Boost Your Frontend Projects: 9 Essential Practices for San CLI Maintenance

Our team maintains several front‑end open‑source projects such as san-cli, san-devtools, santd, san-loader, san-hot-loader, eslint-plugin-san, and san-test-utils. As more contributors join, we face typical open‑source maintenance challenges, especially low‑quality issue reports that hinder bug fixing.

Issues Templates

We start with issue templates. An issue without a template has an empty title and body, making it hard to reproduce bugs. In San CLI we created two templates— bug and feature —so that new issues automatically include fields for version, description, and reproduction steps. To set up templates, go to the repository’s Settings page, click the large green Set up templates button, and add markdown files under .github/ISSUE_TEMPLATE. The templates can be edited later by modifying those markdown files.

Code Standards

Consistent code style is essential. We use eslint together with husky and lint‑staged to enforce standards automatically.

eslint

Install eslint and add a script entry in package.json: "scripts": { "lint": "eslint ./" } Run yarn lint or npm run lint to see lint errors in the console.

To apply a custom company style, install @ecomfe/eslint-config and reference it in the .eslintrc file, disabling the comma‑dangle rule as needed.

husky

Install husky and add a pre‑commit hook in package.json that runs yarn lint. This ensures linting runs on every commit; if linting fails, the commit is aborted.

lint‑staged

To lint only changed files, install lint‑staged and replace the pre‑commit script with lint‑staged. Configure it to run eslint on * (all staged files). This dramatically reduces the time spent on each commit.

Unit Testing

Automate unit tests in the same pre‑commit hook. Add a command such as jest after the lint step so that a failing test also blocks the commit. Run shorter checks first (lint) to give fast feedback before the longer test suite.

Commit Message Standards

Consistent commit messages improve readability and enable automatic changelog generation. Use commitlint (core package @commitlint/cli) together with husky ’s commit‑msg hook. Install the CLI and a conventional config, then add the hook in package.json. Invalid messages abort the commit.

Continuous Integration (CI)

Local checks can be bypassed with -n or --no‑verify, so we also run the same lint, test, and commit‑message checks on the CI server. GitHub Actions is preferred over Travis CI because it is faster, integrates natively, and provides clearer logs.

In a workflow file under .github/workflows, define jobs that run on push or pull_request to install dependencies ( yarn) and execute yarn test. The CI results appear as green checkmarks or red crosses next to each PR.

GitHub Badges

Badges are image links placed in README.md to display project status (e.g., build passing, issue count). They can be obtained from the official GitHub documentation or from shields.io when no official badge exists.

Monitoring npm Packages

Use Snyk to monitor dependency versions. When a vulnerable version is detected, Snyk opens a PR to upgrade the package and sends an email notification. In our experience, Snyk’s PRs are often closed manually because upgrades may introduce breaking changes.

CHANGELOG

A changelog records notable changes per version. It can be generated automatically with semantic-release, which determines the next version from conventional commit messages and optionally creates a CHANGELOG.md. This requires the project to follow a standard commit‑message format.

Contribution Guide

Create a CONTRIBUTING.md file in the .github folder to explain how to open PRs, run the project locally, and follow the coding standards. Reference the GitHub documentation and the Open‑Source Guide for detailed examples.

Summary

The nine "bricks"—issue templates, code linting, unit testing, commit‑message linting, CI, GitHub badges, npm‑package monitoring, changelog automation, and contribution guidelines—form a comprehensive front‑end engineering workflow that improves code quality, reduces maintenance overhead, and encourages healthy open‑source collaboration.