Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
124 lines (84 loc) · 6.92 KB

CONTRIBUTING.md

File metadata and controls

124 lines (84 loc) · 6.92 KB
Raw

Contributing to jQuery Form

Want to contribute to jQuery Form? That's great! Contributions are most welcome! Here are a couple of guidelines that will help you contribute. Before we get started: Please note that this project is released with a Contributor Code of Conduct to ensure that this project is a welcoming place for everyone to contribute to. By participating in this project you agree to abide by its terms.

Overview

Contribution workflow

  1. Fork the repository in GitHub with the Fork button.
  2. Branch from main into a short-lived topic branch (e.g. new-feature):
    git checkout -b new-feature
  3. Make your feature addition or bug fix.
  4. After setting up your testing enviroment, run the tests:
npm test

If the tests all pass, move on to step 5.

  1. Open a pull request against main. Topic branches only—do not PR into long-lived integration branches that no longer exist (develop, etc.).
  • Please make sure all of your commits are atomic (one feature per commit).
  • Use sensible commit messages.
    • Always write a clear log message for your commits. One-line messages are fine for small changes, but bigger changes should look like this:
    $ git commit -m "A brief summary of the commit"
>
> A paragraph describing what changed and its impact."
  • If your PR fixes a separate issue number, include it in the commit message.

Things to keep in mind

  • Smaller PRs are likely to be merged more quickly than bigger changes.
  • Every merge needs maintainer review. Feature/community PRs wait until the modernization coverage work is done (see the plan); they are not merged before that gate.
  • This project is using Semantic Versioning 2.0.0

Branching and releases

Full rationale: ADR-0002.

  • main is the only trunk. Work in short-lived branches; open PRs into main.
  • 4.x then 5.0 are sequential on main (no standing next branch). After 5.0, rare 4.x patches use an on-demand release/4.x branch cut from the last v4 tag.
  • npm: latest tracks the current major; after 5.0, 4.x publishes use the v4 dist-tag.
  • Releases: maintainers bump the version, tag vX.Y.Z, and publish to npm manually. CI verifies; it does not publish.

Testing

jQuery Form uses Node.js, Rollup, ESLint, Prettier, and Vitest browser mode to build and validate the source. Here is how to set that up:

  1. Install the Node.js version in .nvmrc (with nvm: nvm use).
  2. Install dependencies and the test browser:
npm ci
npx playwright install chromium
  1. Run lint, the build, and the tests:
npm test

Edit src/jquery.form.js (an ES module), never dist/. npm test rebuilds dist/; commit the rebuilt files with your change, since CI fails if they differ from the build.

Git blame

Repo-wide formatting commits are listed in .git-blame-ignore-revs. To skip them in git blame:

git config blame.ignoreRevsFile .git-blame-ignore-revs

Reporting a bug

So you've found a bug, and want to help us fix it? Before filing a bug report, please double-check the bug hasn't already been reported. You can do so on our issue tracker. If something hasn't been raised, you can go ahead and create a new issue with the following information:

  • Which version of the plugin are you using?
  • Which version of the jQuery library are you using?
  • What browsers (and versions) have you tested in?
  • How can the error be reproduced?
  • If possible, include a link to a JSFiddle or CodePen example of the error.

If you want to be really thorough, there is a great overview on Stack Overflow of what you should consider when reporting a bug.

It goes without saying that you're welcome to help investigate further and/or find a fix for the bug. If you want to do so, just mention it in your bug report and offer your help!

Contributing to an existing issue

Finding an issue to work on

We've got a few open issues and are always glad to get help on that front. You can view the list of issues here. (Here's a good article on how to find your first bug to fix).

Before getting to work, take a look at the issue and at the conversation around it. Has someone already offered to work on the issue? Has someone been assigned to the issue? If so, you might want to check with them to see whether they're still actively working on it.

If the issue is a few months old, it might be a good idea to write a short comment to double-check that the issue or feature is still a valid one to jump on.

Feel free to ask for more detail on what is expected: are there any more details or specifications you need to know? And if at any point you get stuck: don't hesitate to ask for help.

Making your contribution

We've outlined the contribution workflow here. If you're a first-timer, don't worry! GitHub has a ton of guides to help you through your first pull request: You can find out more about pull requests here and about creating a pull request here.

Feature Requests

  • You can request a new feature by submitting an issue.
  • If you would like to implement a new feature:
    • For a Major Feature, first open an issue and outline your proposal so that it can be discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
    • Small Features can be crafted and directly submitted as a Pull Request.

Additional info

Especially if you're a newcomer to Open Source and you've found some little bumps along the way while contributing, we recommend you write about them. Here's a great article about why writing about your experience is important; this will encourage other beginners to try their luck at Open Source, too!