Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(66)

Side by Side Diff: sdk/lib/_internal/pub/README.md

Issue 63283006: Add a README describing how to contribute to pub. (Closed) Base URL: https://dart.googlecode.com/svn/branches/bleeding_edge/dart
Patch Set: code review Created 7 years, 1 month ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch | Annotate | Revision Log
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
(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
OLDNEW
« no previous file with comments | « no previous file | no next file » | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698