|
0
|
1 # Contributing to Shoestring
|
|
|
2
|
|
|
3 Contributions are appreciated. In order for us to consider including a contribution, it does have to meet a few criteria:
|
|
|
4
|
|
|
5 * Code is specific to one issue (eg. feature, extension or bug)
|
|
|
6 * Code is formatted according to JavaScript Style Guide.
|
|
|
7 * Code has full test coverage and all tests pass.
|
|
|
8
|
|
|
9 ## Feature Parity
|
|
|
10
|
|
|
11 Shoestring isn't attempting to reach feature parity with jQuery. It may not even support the same invocation patterns for included methods. To prevent surprises we've started adding exceptions into the `-dev` builds so that when a feature isn't supported it's obvious. If you find a feature missing (other than an absent method/object) please consider adding an `error` call and a descriptive error message. For example, in `src/extensions/dom/prev.js`:
|
|
|
12
|
|
|
13 ```javascript
|
|
|
14 shoestring.fn.prev = function(selectors){
|
|
|
15 var ret = [], next;
|
|
|
16
|
|
|
17 //>>includeStart("development", pragmas.development);
|
|
|
18 if( selectors ){
|
|
|
19 shoestring.error( 'prev-selector' );
|
|
|
20 }
|
|
|
21 //>>includeEnd("development");
|
|
|
22
|
|
|
23 this.each(function(){
|
|
|
24 next = this.previousElementSibling;
|
|
|
25 if( next ){
|
|
|
26 ret = ret.concat( next );
|
|
|
27 }
|
|
|
28 });
|
|
|
29
|
|
|
30 return shoestring(ret);
|
|
|
31 };
|
|
|
32 ```
|
|
|
33
|
|
|
34 Here, we're throwing an error if the selectors argument is passed since we don't support that invocation pattern. **Note** the pragmas are defined so that they are only included in development builds and should be duplicated at other locations. To define or change the message associated with `prev-selector` see `src/util/errors.js`:
|
|
|
35
|
|
|
36 ```javascript
|
|
|
37 shoestring.enUS = {
|
|
|
38 errors: {
|
|
|
39
|
|
|
40 ...
|
|
|
41
|
|
|
42 'prev-selector' : "Shoestring does not support passing selectors into .prev, try .prev().filter(selector)"
|
|
|
43
|
|
|
44 ...
|
|
|
45
|
|
|
46 }
|
|
|
47 };
|
|
|
48
|
|
|
49 ```
|
|
|
50
|
|
|
51 ## Code to an Issue
|
|
|
52
|
|
|
53 Use a separate git branch for each contribution. Give the branch a meaningful name.
|
|
|
54 When you are contributing a new extensions use the name of this extension, like `dom-toggleclass`.
|
|
|
55 Otherwise give it a descriptive name like `doc-generator` or reference a specific issue like `issues-12`.
|
|
|
56 When the issue is resolved create a pull request to allow us to review and accept your contribution.
|
|
|
57
|
|
|
58 **NOTE** All changes are considered carefully but additions especially so. We are particularly interested in retaining a small footprint and if a method is present, history tells us that someone will use it.
|
|
|
59
|
|
|
60 ## JavaScript Style Guide
|
|
|
61
|
|
|
62 Code should be formatted according to the [jQuery JavaScript Style Guide](http://contribute.jquery.org/style-guide/).
|
|
|
63
|
|
|
64 ## Test coverage
|
|
|
65
|
|
|
66 Code should be covered by unit tests. The tests are located in `test/unit/` and written in [QUnit](http://qunitjs.com/).
|
|
|
67 When you add a new feature like an extension. Make sure to also add tests for your new code, for this case in `test/unit/extensions.js`.
|
|
|
68 To check if all tests pass run `grunt qunit`. You can use `grunt watch` to continuously run the tests while you develop.
|
