OLD | NEW |
| (Empty) |
1 --- | |
2 title: "Command: Upgrade" | |
3 --- | |
4 | |
5 $ pub upgrade [PACKAGE] | |
6 | |
7 Without any additional arguments, `pub upgrade` gets the latest versions of | |
8 all the dependencies listed in the [`pubspec.yaml`](pubspec.html) file in the | |
9 current working directory, as well as their [transitive | |
10 dependencies](glossary.html#transitive-dependencies), to the `packages` | |
11 directory located next to the pubspec. For example: | |
12 | |
13 $ pub upgrade | |
14 Dependencies upgraded! | |
15 | |
16 When `pub upgrade` upgrades dependency versions, it writes a | |
17 [lockfile](glossary.html#lockfile) to ensure that future [`pub | |
18 get`s](pub-get.html) will use the same versions of those dependencies. | |
19 Application packages should check in the lockfile to source control; this | |
20 ensures the application will use the exact same versions of all dependencies for | |
21 all developers and when deployed to production. Library packages should not | |
22 check in the lockfile, though, since they're expected to work with a range of | |
23 dependency versions. | |
24 | |
25 If a lockfile already exists, `pub upgrade` will ignore it and generate a new | |
26 one from scratch using the latest versions of all dependencies. This is the | |
27 primary difference between `pub upgrade` and `pub get`, which always tries to | |
28 get the dependency versions specified in the existing lockfile. | |
29 | |
30 ## Upgrading specific dependencies | |
31 | |
32 It's possible to tell `pub upgrade` to upgrade specific dependencies to the | |
33 latest version while leaving the rest of the dependencies alone as much as | |
34 possible. For example: | |
35 | |
36 $ pub upgrade unittest args | |
37 Dependencies upgraded! | |
38 | |
39 Upgrading a dependency upgrades its transitive dependencies to their latest | |
40 versions as well. Usually, no other dependencies are updated; they stay at the | |
41 versions that are locked in the lockfile. However, if the requested upgrades | |
42 cause incompatibilities with these locked versions, they will be selectively | |
43 unlocked until a compatible set of versions is found. | |
44 | |
45 ## Getting a new dependency | |
46 | |
47 If a dependency is added to the pubspec before `pub upgrade` is run, it will | |
48 get the new dependency and any of its transitive dependencies and place them in | |
49 the `packages` directory. This is the same behavior as `pub get`. | |
50 | |
51 ## Removing a dependency | |
52 | |
53 If a dependency is removed from the pubspec before `pub upgrade` is run, it | |
54 will remove the dependency from the `packages` directory, thus making it | |
55 unavailable for importing. Any transitive dependencies of the removed dependency | |
56 will also be removed, as long as no remaining immediate dependencies also depend | |
57 on them. This is the same behavior as `pub get`. | |
58 | |
59 ## Upgrading while offline | |
60 | |
61 If you don't have network access, you can still run `pub upgrade`. Since pub | |
62 downloads packages to a central cache shared by all packages on your system, it | |
63 can often find previously-downloaded packages there without needing to hit the | |
64 network. | |
65 | |
66 However, by default, pub will always try to go online when you upgrade if you | |
67 have any hosted dependencies so that it can see if newer versions of them are | |
68 available. If you don't want it to do that, pass the `--offline` flag when | |
69 running pub. In this mode, it will only look in your local package cache and | |
70 try to find a set of versions that work with your package from what's already | |
71 available. | |
72 | |
73 Keep in mind that pub *will* generate a lockfile after it does this. If the | |
74 only version of some dependency in your cache happens to be old, this will lock | |
75 your app to that version. The next time you are online, you will likely want to | |
76 run `pub upgrade` again to upgrade to a later version. | |
OLD | NEW |