Skip to content

Latest commit

 

History

History
161 lines (106 loc) · 6.26 KB

CONTRIBUTING.md

File metadata and controls

161 lines (106 loc) · 6.26 KB
Raw

Contributing to Twind

Thanks for checking out Twind! Please read on to learn how you can help make this project even better.

Reporting Issues

Found a problem? Want a new feature?

Remember, a bug is a demonstrable problem caused by our code.

Ways to help

Regardless of your experience level, there are ways that you can help:

  • Share the project on Twitter
  • Star the project on Github
  • Tell your friends/co-workers about Twind
  • Write an article about Twind on Medium, Dev, or your platform of choice
  • Create written or video tutorials about Twind
  • Report bugs or provide feedback by creating issues
  • Contribute to the source code by fixing bugs/issues or helping us build new features

Financial contributions

We also welcome financial contributions in full transparency on our open collective. Anyone can file an expense. If the expense makes sense for the development of the community, it will be "merged" in the ledger of our open collective by the core contributors and the person who filed the expense will be reimbursed.

How to create a good bug report

To be able to fix issues we need to see them on our machine. This is only possible when we can reproduce the error. The easiest way to do that is narrow down the problem to specific components or combination of them. This can be done by removing as much unrelated code as possible.

The perfect way to do that is to make a codesandbox. That way you can easily share the problematic code and ensure that others can see the same issue you are seeing.

For us a codesandbox says more than a 1000 words 🎉

Documentation changes

All documentation for SvelteKit is in the documentation directory, and any improvements should be made as a Pull Request to this repository. The documentation is served via an API; the site itself is located in the sites repository.

If you wish to preview documentation changes locally, please follow the instructions here: Previewing local docs changes.

Submitting Pull Requests

Pull requests are the greatest contributions, so be sure they are focused in scope and avoid unrelated commits.

  • If adding a new feature:

    • Add accompanying test case.
    • Provide a convincing reason to add this feature. Ideally, you should open a suggestion issue first and have it approved before working on it.

  • If fixing bug:

    • If you are resolving a special issue, add (fix #xxxx[,#xxxx]) (#xxxx is the issue id) in your PR title for a better release log, e.g. fix: update entities encoding/decoding (fix #3899).
    • Provide a detailed description of the bug in the PR. Live demo preferred.
    • Add appropriate test coverage if applicable.

  • It's OK to have multiple small commits as you work on the PR - we will automatically squash them before merging. Please do not force push commits — this makes the conversation difficult to follow.

  • Make sure tests pass!

  1. To begin: fork this project, clone your fork, and add our upstream.

    # Clone your fork of the repo into the current directory
git clone [email protected]:$(npx github-username-cli $(git config user.email))/twind.git

# Navigate to the newly cloned directory
cd twind

# Assign the original repo to a remote called "upstream"
git remote add upstream [email protected]:tw-in-js/twind.git

  2. Local development

    The Twind repo is a monorepo using pnpm workspaces. The package manager used to install and link dependencies must be pnpm.

    To develop and test a twind package:

    1. Run pnpm install in twind's root folder

    2. Run pnpm test to run all tests

  3. Create a branch for your feature or fix:

    # Move into a new branch for your feature
git checkout -b feature/thing
    # Move into a new branch for your fix
git checkout -b fix/something

  4. Generating changelogs

    For changes to be reflected in package changelogs, run pnpx changeset and follow the prompts. All changesets should be patch until Twind 1.0

    pnpx changeset

  5. If your code passes all the tests, then push your feature branch:

    # Test current code
pnpm test # or npm test

# Build current code
pnpm build # or npm run build

    Note: ensure your version of Node is 14 or higher to run scripts

    # Push the branch for your new feature
git push origin feature/thing
    # Or, push the branch for your update
git push origin update/something

That’s it! Now open a pull request with a clear title and description.

Testing Twind against external packages

You may wish to test your locally-modified copy of Twind against another package that is using it. For pnpm, after building Twind, you can use pnpm.overrides. Please note that pnpm.overrides must be specified in the root package.json and you must first list the package as a dependency in the root package.json:

{
  "dependencies": {
    "@twind/core": "*"
  },
  "pnpm": {
    "overrides": {
      "@twind/core": "link:../path/to/twind/packages/core"
    }
  }
}

And re-run pnpm install to link the package.

Releases

The Changesets GitHub action will create and update a PR that applies changesets and publishes new versions of changed packages to npm.

It uses pnpm publish rather than pnpx changeset publish so that we can use the --filter and (while in beta) --tag flags — though perhaps they work with pnpx changeset publish?