Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/finsweet/attributes/llms.txt

Use this file to discover all available pages before exploring further.

This guide covers the process for submitting pull requests to the Attributes project.

Before You Start

For New Features

If you would like to request a new feature or enhancement but are not yet thinking about opening a pull request, you can file an issue with the feature template.

For New Attributes

If you want to propose a completely new Attribute solution, please create an RFC. A good Request for Comments (RFC) should include:
  • A clear description of the new Attribute solution and its purpose
  • A breakdown of all the HTML attributes that will be used
  • A use case example

For Bug Fixes

If you’re only fixing a bug, it’s fine to submit a pull request right away, but we still recommend that you file an issue detailing what you’re fixing. This is helpful in case we don’t accept that specific fix but want to keep track of the issue.

Creating Your Branch

1. Fork the Repository

Fork the repository to your own GitHub account.

2. Create a Branch

Create your branch from master:
git checkout master
git pull origin master
git checkout -b my-feature-branch
Important: If you need to create a fix for Attributes v1, create a branch from v1 instead:
git checkout v1
git pull origin v1
git checkout -b my-v1-fix-branch

Development Process

1. Make Your Changes

Develop your feature or fix in your branch. Keep your changes focused and atomic.

2. Test Your Changes

Ensure all tests pass:
pnpm test
If you’re adding new functionality, include tests for it. All tests are located in packages/attributes/tests.

3. Lint and Typecheck

Always lint and typecheck your code before submitting:
pnpm lint
pnpm check
To automatically fix linting issues:
pnpm lint:fix

Submitting Your Pull Request

1. Push Your Branch

Push your branch to your fork:
git push origin my-feature-branch

2. Open a Pull Request

Go to the Attributes repository and open a new pull request.

3. Fill Out the PR Template

Make sure to:
  • Provide a clear title - Summarize what your PR does
  • Describe the changes - Explain what you changed and why
  • Reference related issues - Link to any related issues or discussions
  • Include screenshots - If your changes affect the UI, include before/after screenshots
  • List breaking changes - Clearly note any breaking changes

4. Keep It Small

Small pull requests are much easier to review and more likely to get merged. If you have a large feature:
  • Break it into smaller, logical pieces
  • Submit multiple PRs if necessary
  • Each PR should be independently reviewable

Review Process

What to Expect

  1. Automated checks - CI will automatically run tests and linting
  2. Code review - A maintainer will review your code
  3. Feedback - You may be asked to make changes
  4. Approval - Once approved, your PR will be merged

Responding to Feedback

If changes are requested:
  1. Make the requested changes in your branch
  2. Push the changes to your fork
  3. The PR will automatically update
  4. Reply to comments to indicate you’ve addressed them

Reporting Issues

Bug Reports

We use GitHub Issues to track bugs and feature requests. When opening a new issue, always make sure to fill out the issue template. This step is very important! Not doing so may result in your issue not being managed in a timely fashion. Guidelines:
  • One issue, one bug - Please do not combine multiple issues into one
  • Provide reproducible steps - Include a clear set of steps to reproduce the issue. This will help us understand the problem better and fix it faster
  • Check for duplicates - Take a look around and see if someone already opened an issue about it

Questions and Support

If you have questions about using Attributes, please use the Finsweet forum. The issue list of this repository is exclusively for bugs and feature requests.

License

By contributing to Attributes, you agree that your contributions will be licensed under the Apache 2.0 License.

Build docs developers (and LLMs) love