Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 # Contibuting to pub | |
| 2 | |
| 3 Thanks for being interested in contributing to pub! Contributing to a new | |
| 4 project can be hard: there's a lot of new code and practices to learn. This | |
| 5 document is intended to get contributors up and running as quickly as possible. | |
|
Bob Nystrom
2013/11/15 01:44:09
"contributors" -> "you"
nweiz
2013/11/15 21:59:41
Done.
| |
| 6 If you're looking for documentation on using pub, try | |
| 7 [pub.dartlang.org](http://pub.dartlang.org/doc). | |
| 8 | |
| 9 The first step towards contributing is to contact the pub dev team and let us | |
| 10 know what you're working on, so we can be sure not to start working on the same | |
| 11 thing at the same time. Just send an email to [nweiz@google.com] and | |
| 12 [rnystrom@google.com] letting us know that you're interested in contributing and | |
|
Bob Nystrom
2013/11/15 01:44:09
Maybe just point them at misc@?
nweiz
2013/11/15 21:59:41
Done.
| |
| 13 what you plan on working on. This will also let us give you specific advice | |
| 14 about where to start. | |
| 15 | |
| 16 [nweiz@google.com]: mailto:nweiz@google.com | |
| 17 [rnystrom@google.com]: mailto:rnystrom@google.com | |
| 18 | |
| 19 ## Organization | |
| 20 | |
| 21 Pub isn't a package, but it's organized like one. It has four top-level | |
| 22 directories: | |
| 23 | |
| 24 * `lib/` contains the implementation of pub. Currently, it's all in `lib/src/`, | |
| 25 since there are no libraries intended for public consumption. | |
| 26 | |
| 27 * `test/` contains the tests for pub. | |
| 28 | |
| 29 * `bin/` contains `pub.dart`, the entrypoint script that's run whenever a user | |
| 30 types "pub" on the command line or runs it in the Dart editor. This is usually | |
| 31 run through shell scripts in `sdk/bin` at the root of the Dart repository. | |
| 32 | |
| 33 * `resource/` contains static resource files that pub uses. They're | |
| 34 automatically distributed in the Dart SDK. | |
| 35 | |
| 36 It's probably easiest to start diving into the codebase by looking at a | |
| 37 particular pub command. Each command is encapsulated in files in | |
| 38 `lib/src/command/`. | |
| 39 | |
| 40 ## Running pub | |
| 41 | |
| 42 To run pub from the Dart repository, first [build Dart][building]. From the root | |
| 43 of the repo: | |
| 44 | |
| 45 ./tools/build.py -m release | |
| 46 | |
| 47 You'll need to re-build whenever you sync the repository, but not when you | |
| 48 modify pub or any packages it depends on. To run pub, just run `sdk/bin/pub` (or | |
| 49 `sdk/bin/pub.bat` on Windows). | |
| 50 | |
| 51 [building]: https://code.google.com/p/dart/wiki/Building | |
| 52 | |
| 53 ## Testing pub | |
| 54 | |
| 55 Before any change is made to pub, all tests should pass. To run all the pub | |
| 56 tests, run this from the root of the Dart repository: | |
| 57 | |
| 58 ./tools/test.py -m release pub | |
| 59 | |
| 60 Changes to pub should be accompanied by one or more tests that exercise the new | |
| 61 functionality. When adding a test, the best strategy is to find a similar test | |
| 62 in `test/` and follow the same patterns. Note that pub makes wide use of the | |
| 63 [scheduled_test] package in its tests, so it's usually important to be familiar | |
| 64 with that when adding tests. | |
| 65 | |
| 66 [scheduled_test]: http://pub.dartlang.org/packages/scheduled_test | |
| 67 | |
| 68 Pub tests come in two basic forms. The first, which is usually used to unit test | |
| 69 classes and libraries internal to pub, has many tests in a single file. This is | |
| 70 used when each test will take a short time to run. For example, | |
| 71 `test/version_test.dart` contains unit tests for pub's Version class. | |
| 72 | |
| 73 The other form, used by most pub tests, is usually used for integration tests of | |
| 74 user-visible pub commands. Each test has a file to itself, which is named after | |
| 75 the test description. This is used when tests can take a long time to run to | |
| 76 avoid having the tests time out when running on the build bots. For example, | |
| 77 `tests/get/hosted/get_transitive_test.dart` tests the resolution of transitive | |
| 78 hosted dependencies when using `pub get`. | |
| 79 | |
| 80 When testing new functionality, it's often useful to run a single test rather | |
| 81 than the entire test suite. You can do this by appending the path to the test | |
| 82 file to the test command. For example, to run `get/relative_symlink_test.dart`: | |
| 83 | |
| 84 ./tools/test.py -m release pub/get/relative_symlink_test | |
| 85 | |
| 86 ## Landing your patch | |
| 87 | |
| 88 All patches to the Dart repo, including to pub, need to undergo code review | |
| 89 before they're submitted. The full process for putting up your patch for review | |
| 90 is [documented elsewhere][contributing]. | |
| 91 | |
| 92 [contributing]: https://code.google.com/p/dart/wiki/Contributing | |
| OLD | NEW |