Contributing to RequireJS
- Why a CLA?§ 1
- Code style§ 2
For something that is bigger than a one or two line fix:
- Create your own fork of the code
- Do the changes in your fork
- If you like the change and think the project could use it:
- Be sure you have followed the code style for the project.
- Sign the Contributor License Agreement, CLA, with the jQuery Foundation.
- Note the jQuery Foundation Code of Conduct.
- Send a pull request indicating that you have a CLA on file.
For one or two line fixes, you can use the RequireJS GitHub Issues page to indicate the problem. You can also do the full fork/pull request as mentioned above, but a CLA is not needed for one or two line fixes.
Why a CLA?§ 1
CLAs are common with open source projects, with the Apache projects probably being the most well known. The goal is to allow RequireJS to be used in as many projects as possible, and for some companies, using only CLA-approved code is the best option.
You still own the copyright on your contribution, the CLA just gives the most flexibility for licensing, and assures the lineage of the intellectual property. You should only submit patches for your own intellectual property, and not the intellectual property of others.
Additional reading that may be helpful:
Code Style§ 2
JSLint is used for checking code style. It is also useful for avoiding some errors. The default settings on JSLint should be fine to use, in particular, 4 spaces for indentation, do not use tabs.
camelCase should be used for all variables and file names. Avoid the use of underscores as word separators. This extends to things like CSS class names, IDs in test HTML documents, everything.
Some exceptions to JSLint can be indicated at the top of each JS file, but they should be avoided when possible. Two common exceptions you may see in the source:
- nomen: false, allow underscore at the beginning of some property/variable/function names.
- plusplus: false, but only to allow for loops with an incrementing ++ value. Other uses of ++ should be avoided.