-
Are you opening an issue? Please take a look at issue chapter.
-
Are you creating a pull request? Please take a look at pull request chapter.
b. Updating an existing library
e. P.S.
-
Before opening a issue ticket, please check if there is/was already an issue on the same topic.
-
If you are going to open a issue about your library (means you are the author/maintainer or one of the main authors/maintainers), please add
[author]
on the issue topic, we'll give it a higher priority to process. -
Please tag obviously related people or issues or commits on the issue as cc (carbon copy). For example, @PeterDaveHello / #3388 / 51e1bd713f
-
Before sending a pull request, please sync/update your own repository with our master HEAD.
-
If you are not the author or maintainer of the lib, please tell us where are those files from, like the url of its download page, or the url of releases page of the library.
- If you are the author or maintainer of the lib, please just add
[author]
in th pull request's title.
-
If you are adding a new lib into cdnjs, please add
[new]
in the pull request's title. -
If it doesn't have officially minified files, please minify all of the main css/js files, and give them a file name as
library.min.js
.
- cdnjs's preferred JavaScript minifier is UglifyJS
- You can also use web-minify-helper to help you do this automatically, it supports both css and js.
- Filenames should not include a version number and be lowercase.
- This is OK:
useful.min.js
, but this is not:useful-2.0.1.min.js
.
-
Only do one thing or strongly related works in one commits, don't mix different things into the same commit.
-
Every commit should be meaningful, don't cut one thing into multiple commits, unless you are trying to fix an existing problem in the master branch.
- Like adding a lib, but it has some problem, so come with many commits to fix, that will not be allowed.
-
Do not do things which are not related with your commit log.
-
We only host the css/js libs with production version, unless the project is very popular, like jQuery, this is for maintainer to decide.
- If you have a good reason to host a alpha/beta/RC or other non-production version, please feel free to explain in comments.
-
If you are asked to modify the commits, please use
git commit --amend
/git rebase
to update your commits, and use--force
parameter with git push to update the pull request. -
You should go back to the PR page after you sent the PR for 15~25 mins, and check if you passed the CI build, if not, please take a look at the error message and try to fix, we won't merge a PR with a failed build.
- Feel free to ask for help if you have no idea.
- Please try to maintain consistency with the existing file and directory structure.
- If you think the old structure is wrong, or the structure obviously changed in the new version, please add notes in the commit log or pull request comment.
-
Please don't forget to update the version info to the latest stable version in its
package.json
. -
Make sure the main file, as known as the
filename
property inpackage.json
is correct, different versions may use different filename.
- Libraries are stored in the ajax/libs directory. Each library has its own subdirectory of ajax/libs and each version of the library has its own subdirectory of the library directory name, for example:
/ajax/libs/jquery/2.0.0/
- We use
package.json
to store the meta data of a library in npm format, please don't forget to add this file at the root of the lib.
- If there is an official
package.json
, please try to follow the official version, the best way is just copy from the official and do a little modification of it. - If there is not an official
package.json
, please create it by yourself, you should refer to doc of package.json orother lib'spackage.json
, and the data should be as close as official data as possible. - If you will create its
package.json
, the indent of it must be2 spaces
, others will be fine to follow official version or to use 2 spaces. - Please use JSONLint to validate your
package.json
.
-
We use the directory/folder name and
name
property inpackage.json
to identify a library, so this two string should be totally equal. -
You must do
npm test
under the root directory of this project to make sure everything is fine.
- Please refer to Install npm test dependencies & Run npm test to check all is well.
- Have you comply with our conventions?
- Have you followed the library directory structure?
- Does a valid and accurate
package.json
exist for the library? - Have you minified JavaScript and CSS?
- Did
npm test
check out OK?
-
Because of the characteristic of git, it'll be better to do the work on Unix-like environment, like Linux or BSD distributions (not including Mac).
-
If you think this doc is too simple or casual, please refer to README file or another detail version of CONTRIBUTING-WIP doc.
- If there are some conflicts between these files, the priority should be like this: README > CONTRIBUTING > CONTRIBUTING-WIP, and you can help us to open a issue and discuss, fix it.
-
If the library has official npm package, please try to maintain it with npm auto update.
-
It'll always be better to compare the diff before committing and sending pull request.
- You can use
git diff
before committing, and usegit log -p
orgit show sha1hash
to compare the difference.
-
Maintainers may force take the task away if there is no response on the pull request for days.
-
It'll be better to update/sync your branch again by rebase after your PR was asked to modify something.
- You must do this if your PR was opened for more than 1 week, or maintainers may take the task away.
Finally, thank you so much for your contribution, hope we can make the best cdn service on the world :)