Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
167 lines (127 loc) · 4.72 KB

CONTRIBUTING.md

File metadata and controls

167 lines (127 loc) · 4.72 KB

Contributing

First setup

  1. Install required tools.
  2. Fork and clone the repository.
  3. Open it in your favorite editor. VSC is recommended. For small changes you can also use web-based GitHub editor.
  4. Open terminal. You can use built-in VSC terminal.
  5. Run deno install to install required client dependencies.
  6. Run go mod download to install required server dependencies (optional).
  7. Run deno task init to create .env file and initialize the database. noenv and nodb options are available.
  8. Run deno task compile:client to create client files.
  9. Change the .env file.
    • Set up server connection with SQLite.
    • Set up JWT secret.
  10. Run deno task dev to start the server.

Making changes

The best way is to use two terminals, with a third for other tasks:

Note

You can use Visual Studio Code's task commands: Tasks: Run Task.

  • Compile Client & Watch
  • Serve
deno task compile:client watch
deno task dev

Before committing your changes, make sure to run the prepare task to format:

deno task prepare

Resources

How to write commit messages and PR names

Write clear, concise PR titles that explain the "why" behind changes.

We use Conventional Commits. Since we squash on merge, the PR title becomes the commit message in main, so it's important to get it right.

Format: type(scope): description

Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert

Scopes (optional): a11y, blog, deps, docs, i18n, ui

Examples:

  • fix: resolve search pagination issue
  • feat: add package version comparison
  • fix(i18n): update French translations
  • chore(deps): update esbuild to v0.8

Where front end changes are made, please include before and after screenshots in your pull request description.

Note

Use lowercase letters in your pull request title. Individual commit messages within your PR don't need to follow this format since they'll be squashed.

About releases

Note

You should be a repository owner or have write access to create a release.

You can create new release and git tag automatically using GitHub workflow.

Available options:

  • patch
  • minor
  • major
  • release
  • alpha patch
  • alpha minor
  • alpha major
  • alpha release
  • beta patch
  • beta minor
  • beta major
  • beta release

Examples:

Release type Result
major 0.0.1 → 1.0.0 → 2.0.0
minor 0.0.1 → 0.1.0 → 0.2.0
patch 0.0.1 → 0.0.2 → 0.0.3
patch 0.0.1.alpha.1 → 0.0.1
patch alpha 0.0.1.alpha.1 → 0.0.2-alpha.0
patch beta 0.0.1.alpha.1 → 0.0.2-beta.0
release 0.0.1.alpha.1 → 0.0.1
release alpha 0.0.1.alpha.1 → 0.0.1-alpha.2
release beta 0.0.1.alpha.1 → 0.0.1-beta.0
alpha 0.0.1.alpha.1 → 1.0.0-alpha.0
beta 0.0.1.alpha.1 → 1.0.0-beta.0

You can get next version and changelog output without creating a release:

deno task release

You can also create a release from your machine, but it is not recommended:

deno task release --force

Compilation

Creating a standalone server binary is useful for deploying the server to production or for distributing it as a standalone application.

Available go build tags:

  • Environment:
    • [none] enables client files watching.
    • prod normal mode.
  • Client embedding:
    • [none] enables client files embedding. The server binary will become standalone.
    • lite disables files embedding. The server binary will use closest ./client/static and ./client/templates directories. This option makes the server binary more flexible and reduces its size.

Example: go -o dist/server.exe -tags lite,prod .

Available deno tasks:

# -tags prod
deno task compile:server
deno task compile:server:cross

# -tags lite
deno task compile:server dev
deno task compile:server:cross dev