1 | * [Install Variations](#install-variations)
|
2 | * [Requiring Packages](#requiring-packages)
|
3 | * [Reproducible Installs](#reproducible-installs)
|
4 | * [Updating Packages](#updating-packages)
|
5 | * [Inspecting Dependencies](#inspecting-dependencies)
|
6 | * [Resolving Conflicts](#resolving-conflicts)
|
7 | * [Uninstalling and Cleaning](#uninstalling-and-cleaning)
|
8 | * [Other Options](#other-options)
|
9 | * [Resolution Algorithm](#resolution-algorithm)
|
10 |
|
11 | ### Install Variations
|
12 |
|
13 | #### Naming
|
14 |
|
15 | Install aliases from the [jspm registry](https://github.com/jspm/registry/blob/master/registry.json):
|
16 |
|
17 | ```
|
18 | jspm install jquery
|
19 | ```
|
20 |
|
21 | This is equivalent to writing:
|
22 |
|
23 | ```
|
24 | jspm install jquery=github:components/jquery
|
25 | ```
|
26 |
|
27 | (`jspm install github:components/jquery` will install into the name `components/jquery` by default otherwise).
|
28 |
|
29 | Multiple installs can be performed by separating installs with a space:
|
30 |
|
31 | ```
|
32 | jspm install jquery bootstrap
|
33 | ```
|
34 |
|
35 | Install from npm:
|
36 |
|
37 | ```
|
38 | jspm install npm:immstruct
|
39 | ```
|
40 |
|
41 | installs `immstruct`.
|
42 |
|
43 | When installing from npm, various build operations are applied to convert Node-style requires into jspm-compatible requires. Sometimes this will break, in which case [please post an issue](https://github.com/jspm/npm/issues).
|
44 |
|
45 | [Read more about configuring installed packages for jspm here](https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm).
|
46 |
|
47 | #### Versioning
|
48 |
|
49 | Install exact versions of packages by specifying the version in the install command:
|
50 |
|
51 | ```
|
52 | jspm install jquery@2.1.0
|
53 | ```
|
54 |
|
55 | This can equally be written:
|
56 |
|
57 | ```
|
58 | jspm install jquery=2.1.0
|
59 | ```
|
60 |
|
61 | Any version tag or branch can be installed this way for GitHub and npm. Commit-based installs are not supported for the GitHub registry currently.
|
62 |
|
63 | Install a version range with -
|
64 |
|
65 | [Semver compatibility range](https://github.com/npm/node-semver#caret-ranges-123-025-004):
|
66 |
|
67 | ```
|
68 | jspm install jquery@^2.1.0
|
69 | ```
|
70 |
|
71 | [Tilde compatibility range](https://github.com/npm/node-semver#tilde-ranges-123-12-1):
|
72 |
|
73 | ```
|
74 | jspm install jquery@~2.1.0
|
75 | ```
|
76 |
|
77 | Arbitrary ranges `x`, `x.y`:
|
78 |
|
79 | ```
|
80 | jspm install jquery@2
|
81 | ```
|
82 |
|
83 | These are the only allowed forms. A literal `x` in ranges and arbitrary version ranges (`>`) are not supported by jspm.
|
84 |
|
85 | ### Requiring Packages
|
86 |
|
87 | Once installed, you can require the package directly by the exact name you installed it into:
|
88 |
|
89 | ```
|
90 | jspm install github:components/jquery
|
91 | ```
|
92 |
|
93 | ```
|
94 | require('components/jquery');
|
95 | require('components/jquery/submodule.js'); // corresponds to /submodule.js in the package path
|
96 | ```
|
97 |
|
98 | Alternatively, we could have aliased jquery on install:
|
99 |
|
100 | ```
|
101 | jspm install jquery=github:components/jquery
|
102 | ```
|
103 |
|
104 | ```
|
105 | require('jquery');
|
106 | require('jquery/submodule.js');
|
107 | ```
|
108 |
|
109 | It is possible to use any names for dependencies in jspm without conflict because each package (including your own code) is given its own completely unique namespace for referring to dependencies. `jquery` can refer to a completely different thing in your own code that a third-party dependency may expect from a `require('jquery')` in its own code.
|
110 |
|
111 | The way this is handled is through [SystemJS contextual map config](https://github.com/systemjs/systemjs/wiki/Map-Configuration), which forms the bulk of the configuration file.
|
112 |
|
113 | > Note everything you import must be directly installed by name into your application. Even if you load a package which depends on jQuery, you still need to install jQuery manually if you want to be able to require it in your own code.
|
114 |
|
115 | ### Reproducible Installs
|
116 |
|
117 | All install ranges are saved in the `package.json` file, with the exact version solution saved in to `config.js`. Both of these files should be checked into version control.
|
118 |
|
119 | To reproduce an install of the `package.json` to the exact version ranges in the `config.js` file, use `jspm install` with no arguments:
|
120 |
|
121 | ```
|
122 | jspm install
|
123 | ```
|
124 |
|
125 | ### Updating Packages
|
126 |
|
127 | To update all installed packages within their version ranges use:
|
128 |
|
129 | ```
|
130 | jspm update
|
131 | ```
|
132 |
|
133 | To update a specific package only:
|
134 |
|
135 | ```
|
136 | jspm update jquery
|
137 | ```
|
138 |
|
139 | ### Inspecting Dependencies
|
140 |
|
141 | To inspect all installed dependencies use `jspm inspect`:
|
142 |
|
143 | ```
|
144 | jspm inspect
|
145 | Installed Versions
|
146 |
|
147 | github:components/jquery 2.1.3
|
148 | github:jspm/nodelibs-fs 0.1.1
|
149 | github:jspm/nodelibs-process 0.1.1
|
150 | github:jspm/nodelibs-util 0.1.0
|
151 | github:systemjs/plugin-json 0.1.0
|
152 | npm:eventemitter3 0.1.6
|
153 | npm:immstruct 1.3.1
|
154 | npm:immutable 3.6.2
|
155 | npm:inherits 2.0.1
|
156 | npm:process 0.10.0
|
157 | npm:util 0.10.3
|
158 |
|
159 | To inspect individual package constraints, use jspm inspect registry:name.
|
160 | ```
|
161 |
|
162 | You can inspect just forks with `jspm inspect --forks` or `jspm inspect -f`
|
163 |
|
164 | To see the install constraints for a given dependency use `jspm inspect registry:name`:
|
165 |
|
166 | ```
|
167 | jspm inspect npm:util
|
168 |
|
169 | Installed versions of npm:util
|
170 |
|
171 | github:jspm/nodelibs-util@0.1.0
|
172 | util 0.10.3 (^0.10.3)
|
173 | ```
|
174 |
|
175 | This shows us all parent dependencies, and the version range they have installed the sub-dependency to.
|
176 |
|
177 | ### Resolving Conflicts
|
178 |
|
179 | It is fine to change dependency versions of dependencies within the `config.js` file manually to alter resolutions.
|
180 |
|
181 | If there is a scenario where you want all versions of a package to resolve to exactly a given version, you can use `resolve --only`:
|
182 |
|
183 | ```
|
184 | jspm resolve --only registry:package@version
|
185 | ```
|
186 |
|
187 | This will ensure that the version solution given is used in all constraints, regardless of whether those constraints are broken.
|
188 |
|
189 | Be very careful using this, as once a version constraint has been broken, say using `jquery@2.1.1` in a range accepting `jquery@^1`, jspm will no longer alter that dependency and consider it manually overridden.
|
190 |
|
191 | ### Uninstalling and Cleaning
|
192 |
|
193 | To uninstall a package:
|
194 |
|
195 | ```
|
196 | jspm uninstall jquery
|
197 | Clearing configuration for github:components/jquery@2.1.3
|
198 | Removing package files for github:components/jquery@2.1.3
|
199 |
|
200 | ok Uninstall complete.
|
201 | ```
|
202 |
|
203 | The package will be removed from the package.json and the package files will also be removed so long as there are no other packages depending on them.
|
204 |
|
205 | Run `jspm clean` at any time to perform this same clearing operation.
|
206 |
|
207 | ### Other Options
|
208 |
|
209 | Use `-o` or `--override` to force-set the package override for a package that needs extra configuration. See https://github.com/jspm/registry#testing-package-overrides.
|
210 | Example:
|
211 | `jspm install github:twbs/bootstrap -o "{ main: 'js/bootstrap', shim: { 'js/bootstrap': ['jquery'] } }"`
|
212 |
|
213 | Use `-f` or `--force` with the install command to ensure the cache is completely refreshed for all installs. Usually this is unnecessary but can be useful if you've made manual edits or have patched registry endpoint code.
|
214 |
|
215 | ### Resolution Algorithm
|
216 |
|
217 | jspm's version resolution algorithm considers every installation process as a tree operation on an existing install tree being merged with a new install tree.
|
218 |
|
219 | When doing a new install the primary dependency being installed (the dependency stored in the package.json) is always installed to its latest version. Any other forks of this package in the existing are always tested for upgrades to this version if possible. This is done to ensure that the code you develop is using dependency versions free of bugs. There is no back-tracking constraint-solving here because ironing out bugs is the primary requirement.
|
220 |
|
221 | Back-tracking does still come into play when looking at sub-dependencies, which are allowed to back-track to minimize forks. If a published package bug fix had needed to push out a bug fix patch for a dependency, it should have bumped its dependency range, so it is assumed that sub-dependencies can be pushed back to their lowest versions so far as is needed within constraint solving.
|
222 |
|
223 | In this way, these resolution solutions are all handled greedily on a case-by-case basis within these trees by the install algorithm.
|
224 |
|
225 | If the install causes an existing dependency to break because of new resolutions, you can revert and install with `jspm install --lock newpackage`. This will then not alter any of the existing resolutions in the tree at all, only performing deduping in the new tree.
|
226 |
|
227 | For further interest, the code for the resolution algorithm can be found in https://github.com/jspm/jspm-cli/blob/master/lib/install.js#L71.
|