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 |