How to Contribute
Take care to read all contributions guidelines before you begin!
- Learn how to contribute to open source.
- Follow a step-by-step guide to practice your first contribution.
- Locate an open issue on GitHub. Let us know you would like to volunteer.
- Optionally, you may coordinate efforts on the
#contributors
channel within Discord. - If the Skeleton team approves your request, you’ll be assigned to the issue.
- Complete the work and submit a pull request and we’ll review the changes.
NOTE: non-trivial PRs submitted without our prior consent will be denied. Repeat offenders will be banned.
Using PNPM
Skeleton makes use of PNPM and PNPM workspaces to maintain all projects within the Skeleton monorepo.
- Install PNPM on your local computer.
- Fork the Skeleton monorepo via the option on GitHub.
- Use Git to clone the forked project to your local machine.
- Point your terminal at one of the sites or package projects listed below.
- Run
pnpm i
to install the required depedencies. - Run
pnpm dev
to start a local dev server for each project.
NOTE: Make sure you’re running
pnpm 9.5.0
or higher. You can check withpnpm --version
.
Adding Dependencies
Dependencies may be installed using the standard pnpm i
command. However, in some cases it may be beneficial to maintain a uniform version shared across multiple projects or within each package.json
. For this we can make use of PNPM Catalogs.
The master version is maintained in the monorepo root in pnpm-workspace.yaml
:
Use the following convention to link each project’s dependency to the shared Catalog version:
Monorepo Structure
Sites
Public facing websites that are deployed to Vercel.
Path | Description |
---|---|
/sites/skeleton.dev | The production skeleton.dev documentation website. |
/sites/next.skeleton.dev | The temporary Next/v3 documentation website. |
/sites/themes.skeleton.dev | The Skeleton themes generator website |
Packages
Modular Skeleton packages distributed via NPM.
Path | Description |
---|---|
/packages/skeleton | The Skeleton core package, containing the Tailwind plugin. |
/packages/skeleton-react | The Skeleton React package, containing Skeleton React components. |
/packages/skeleton-svelte | The Skeleton Svelte package, containing Skeleton Svelte components. |
/packages/create-skeleton-app | The Skeleton onboarding CLI application. |
Branch
Skeleton uses two primary branches. All pull requests should be created from and to the dev
branch.
Branch | Description | Pull Requests |
---|---|---|
dev | Represents the bleeding edge developement branch. | Allowed |
master | Represents the release branch of the all projects. | Never |
PR Branch Conventions
Please use the following naming convention when creating your pull request.
Branch | Role |
---|---|
docs/* | When updating the documentation site. |
feature/* | When implementing a new feature. |
chore/* | When implementing small changes. |
bugfix/* | When implementing feature bugfixes. |
Keep branch names short and semantic, using dashes to seperate words.
Changesets
Changesets are used to automatically generate the changelog for each release. Any contributions made within /packages
must contain a Changeset, contributions within /sites
should not include a Changeset.
Use the following instructions to generate a changeset.
- Make sure you’re within your local pull request feature branch.
- Navigate to the root of the Skeleton monorepo.
- Run
pnpm changeset
to trigger the Changeset CLI. - Follow the instructions when prompted.
- Changeset are added as
.md
files within the/.changeset
directory. - You may edit or revise a Changeset right up until release.
Changesets use semantic version. We recommend the following convention.
Version | Role |
---|---|
major | Do not use. Reserved for maintainers. |
minor | For notable changes, such as a new features. |
patch | For small changes, such as a fixing a typo. |
Changeset descriptions will appear verbatim on the Changelog. Keep it short, semantic, and prefix this like branch names.
Tooling
Skeleton makes use of the following technology to improve the developer experience. It’s recommended you run these tools regularly while working on new contributions, ideally before each commit.
Root Commands
Run the following commands in the monorepo root to recursively check each PNPM workspace project:
pnpm check
- triggers each project’s respective diagnostic tooling, such a Svelte Check.pnpm format
- triggers Prettier to automatically format code to the defined rulesets.pnpm lint
- triggers ES Lint to check for any pending linting issues.pnpm test
- triggers all available test cases using tools such as Vitest.
Local Commands
Additionally, you may also run the local instance of each command. Consult the local package.json
for available options. For format
and lint
commands, use the following syntax to draw from the global configuration, but isolate to the current PNPM workspace:
VS Code Extensions
We recommend the following extensions for VS Code.