b1183b5059
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.
http
HTTP provides an HTTP request API on the client and server. To use
these functions, add the HTTP package to your project with $ meteor add http.
See the HTTP section in the Meteor docs for more details.
Direct access to npm request API
On the server, the http package is implemented using the
npm request module. If you'd like
direct access to this module, you can find it at
HTTPInternals.NpmModules.request.module. Its version can be read at
HTTPInternals.NpmModules.request.version.
Additionally, you can override any request option when using HTTP.call (or
HTTP.get, etc) by including a npmRequestOptions option.
The version of request used may change incompatibly from version to version of
Meteor (or we may even replace it with an entirely different implementation);
use at your own risk.