✔️ Pre-configured for GitHub Codespaces and Gitpod Workspaces

✔️ Straightforward and easy to use, regardless of experience level

✔️ Workflows for testing and publishing to deno.land or nest.land

✔️ Best practice examples for unit testing, project config, CI/CD, and more...

✔️ Built with Deno 🖤

Features by Filename

🧪  ci.yml

Includes CI/CD workflows for automated testing + linting using GitHub Actions. Ensure code quality and formatting are always within specifications

🔖  release.yml

The workflow at .github/workflows/release.yml automatically creates a new Release on your project's repository from every new tag. Just tag and push to create a new release!

🪝  version.ts

By simply exporting prepublish and postpublish functions in version.ts, the publishing workflow can auto-update versions in source files and README.md, to keep examples up-to-date! ¹

🥚  egg.{json,yml}

During the publish workflow, if an egg.json or egg.yml file is present and properly configured, your module will be automatically released on nest.land as well. The integration also enables auto-updating for your project's dependencies (using the eggs update command ²)

››› Read more about the egg.json file and nest.land

This starter kit comes with an egg.json file, to simplify publishing to nest.land using their 'eggs' interface (optional). If you're unfamiliar with Nest.land, it's a decentralized registry that runs on the Arweave network, exclusively for Deno modules. Every version published to their network is immutable - it cannot be edited or deleted, ever.

🚧  package.json

Want to publish a special Node.js version of your module to the npm registry? No sweat! Just include a package.json file (in the same directory as your deno.json file), exactly how you would for a Node project.

During the pre-publish process, pub will recognize this file and use dnt³ to build a Node-compatible version of your module. This includes adding any necessary shims. Unless a valid token exists in the environment as $NPM_TOKEN or $NODE_AUTH_TOKEN, you'll be prompted for credentials to complete the step to publish to NPM.

Getting Started

This section assumes you have the GitHub CLI.

Generate a new repository

Create a new instance with the GitHub CLI, or just create one from your repository homepage on github.com.

gh codespace create --repo deno911/kit

Open in a Gitpod Workspace

Open a new workspace by prepending https://gitpod.io/# to your repository URL and visiting it in your browser:

https://gitpod.io/#https://github.com/deno911/kit

Code on your own machine

gh repo clone [repository]

# or, you can just fork this one:
gh repo fork deno911/kit --clone --remote

Open in Visual Studio Code

code ./[repository]

# or, if you cloned this repo to a dir named "kit":
code ./starter

---

Contributing

This section assumes you have the GitHub CLI

Fork and clone the repository locally

gh repo fork deno911/kit --clone

Create a new branch for your changes

git checkout -b fix/typo-in-readme

Make small changes and concise commits

# hack hack hack...

git commit README.md -m "fix: typos in README.md" && git push

Note: keep the scope of your changes relevant and concise.

🐛  If fixing a bug, be sure to create an Issue first

Unless, of course, you're fixing a bug for which an issue already exists!

This allows the issue to be connected to your Pull Request, creating a permanent record of your contribution to the project. It also makes it easier for maintainers to track project progression.

Creating an issue also ensures you're given proper credit for fixing that bug ;)

Open a Pull Request

gh pr create --title "fix: typos in README.md"

Or just open your repo on github.com and follow the prompts.

Warning: make sure you select the upstream repo for your PR!

---

🅓🅔🅝🅞⑨①①

Footnotes

1. [uses the "pub" command-line interface][pub]\ ↩

2. uses the "eggs" command-line interface\ ↩

3. this feature is still in development 🚧 ↩