1. Add `addAssets` API to `package.js`
2. Rename `getSourcesFunc` to `getFiles` in internal code
3. Changed `PackageAPI#sources` to `PackageAPI#files` with a new structure that
has separate objects for assets and sources
4. Added some tests for different error conditions
5. The same file can now be a source and an asset
Tried to get everything to an rc.0 of the very latest version,
which required some research in some cases about the published
versions. For example, some packages had version histories like:
```
...
1.0.3-winr.2 January 20th, 2015
1.0.3-winr.3 February 24th, 2015 installed
1.0.3 March 17th, 2015 installed
1.0.4-anubhav.0 August 6th, 2015
1.0.4-plugins.0 July 22nd, 2015
1.0.5-galaxy.0 July 17th, 2015
```
In this case, I would bump the version from `1.0.4-plugins.0`
to `1.0.5-rc.0`, skipping `1.0.4`.
This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
In the past, `api.addFiles('foo.gif')` would make foo.gif an asset if
there was no extension handler for gif active. In fact, it would make
it a dual client/server asset even if that was unintentional.
This led to a few problems:
(a) People often left out 'client' and ended up packaging an unnecessary
second server copy of the asset
(b) The implementation meant that `api.addFiles('foo.css')` would actually
add foo.css as a static asset on the server (this was already fixed
on batch-plugins via explicitly looking for wrong-arch
classifications)
(c) Now that we have linters, if a file is used by a linter but not by a
compiler (eg linter config files), there was no way to say in a
package "add this file, but just for linters, don't make it a static
asset too".
These are only really issues in packages, not apps. In apps, we avoid
them by only marking things as static assets if they are in public or
private (and not letting those things be considered as other kinds of
sources).
This is a backwards-incompatible change, but it does not affect apps or
published packages, just packages built from source.
You can use HTTPInternals.NpmModules.request.version to tell what
version of request (if any) is the backend for HTTP.call. This version
may change incompatibly from version to version of Meteor; use at your
own risk.
Fixes#1703.
