Update README.md to reflect dist as the new artifact target directory.
Showing
1 changed file
with
5 additions
and
5 deletions
... | @@ -24,23 +24,23 @@ Make sure to run npm install so that you have all the development dependencies. | ... | @@ -24,23 +24,23 @@ Make sure to run npm install so that you have all the development dependencies. |
24 | 24 | ||
25 | #### Building | 25 | #### Building |
26 | 26 | ||
27 | Rivets.js uses [grunt](http://gruntjs.com/) as the build tool. Run `grunt build` from within the project root to compile + minify the source into */lib*, or just run `grunt` to have it watch the source file for changes — it will compile + minify into */lib* and run the test suite whenever the source file is saved. | 27 | Rivets.js uses [grunt](http://gruntjs.com/) as the build tool. Run `grunt build` from within the project root to compile + minify the source into `dist/`, or just run `grunt` to have it watch the source file for changes. It will compile + minify into `dist/` and run the test suite whenever the source file is saved. |
28 | 28 | ||
29 | #### Testing | 29 | #### Testing |
30 | 30 | ||
31 | Rivets.js uses [Jasmine](http://pivotal.github.com/jasmine/) as the testing framework. You can run the test suite with `grunt spec` or by opening */spec/index.html*. | 31 | Rivets.js uses [Jasmine](http://pivotal.github.com/jasmine/) as the testing framework. You can run the test suite with `grunt spec`. |
32 | 32 | ||
33 | ## Contributing | 33 | ## Contributing |
34 | 34 | ||
35 | #### Bug Reporting | 35 | #### Bug Reporting |
36 | 36 | ||
37 | 1. Ensure the bug can be reproduced on the latest master release. | 37 | 1. Ensure the bug can be reproduced on the latest master. |
38 | 2. Open an issue on GitHub and include an isolated JSFiddle demonstration of the bug. The more information you provide, the easier it will be to validate and fix. | 38 | 2. Open an issue on GitHub and include an isolated [JSFiddle](http://jsfiddle.net/) demonstration of the bug. The more information you provide, the easier it will be to validate and fix. |
39 | 39 | ||
40 | #### Pull Requests | 40 | #### Pull Requests |
41 | 41 | ||
42 | 1. Fork the repository and create a topic branch. | 42 | 1. Fork the repository and create a topic branch. |
43 | 2. Be sure to associate commits to their corresponding issue using `[#1]` or `[Closes #1]` if the commit resolves the issue. | 43 | 2. Be sure to associate commits to their corresponding issue using `[#1]` or `[Closes #1]` if the commit resolves the issue. |
44 | 3. Make sure not to commit any changes under `lib/` as they will surely cause merge conflicts with other's changes. Files under `lib/` are only committed when a new build is released. | 44 | 3. Make sure not to commit any changes under `dist/` as they will surely cause merge conflicts later. Files under `dist/` are only committed when a new build is released. |
45 | 4. Include tests for your changes and make them pass. | 45 | 4. Include tests for your changes and make them pass. |
46 | 5. Push to your fork and submit a pull-request with an explanation and reference to the issue number(s). | 46 | 5. Push to your fork and submit a pull-request with an explanation and reference to the issue number(s). | ... | ... |
-
Please register or sign in to post a comment