This package is depended upon by `cordova-lib`, and npm@3 hoists it to the
top-level dev_bundle/lib/node_modules directory.
We don't use this example app in Meteor, so we don't need it in the dev
bundle. If it is ever needed, developers can run
meteor npm install -g cordova-app-hello-world
To include it in the dev bundle.
It would be really great if we could remove cordova-lib's extra copy of
npm, but that will probably have to wait until they update to npm@3.
These packages need to be installed when we run `npm install` in
`bundle/programs/server` (which this commit ensures), but they don't need
to be part of the dev bundle.
This gives us a reliable place for node-gyp to find the necessary headers
and libraries for compiling binary packages, instead of relying on the
accessibility of $HOME and/or $USERPROFILE.
This reverts commit 64a9312e29.
Although Meteor runs fine on Node 4.5.0, node-gyp doesn't know how to
download libraries appropriate for RC releases, so it looks like we need
to hold off on this upgrade until it's officially out.
Also, just use the vanilla Mongo from mongodb.com.
We used to ship a version with SSL statically compiled in so that `meteor mongo`
to Mother worked. This isn't a thing any more.
If you run `meteor npm install` in bundle/programs/server, this change
means dev_bundle/lib/node_modules/.bin/node-pre-gyp will be available to
packages that need to rebuild binary dependencies, to pick just one
important example.
Building the dev bundle on 32bit Linux wasn't working because node-gyp
needed the npm version and the node version to agree.
Long paths aren't a problem on Mac and Linux like they are on Windows, so
using npm@2.15.1 should be safe here.
Our PR landed in 4.1.0, so we no longer need a fork.
Hopefully, the runas-related bug which causes dev bundle builds to
sometimes fail (which is why we moved the install to its own step) is
fixed with the newer version of runas used by pathwatcher now.
Note that we were previous using a fork with an early version of our PR,
which put the numeric errno on 'code'. The accepted version of the PR
puts the numeric errno on 'errno' (and in Node 0.12, puts a string on
'code').
The ‘show’ command has been completely rewritten. It has different output
and now does the following:
- Interacts with local package versions. Checks in the local package catalog, and
returns the local versions along with the server versions. When ‘meteor show’ is
run with a specific version request (‘meteor show foo@<version>’), default to
showing the local package version (but show a message that a server version is
available). Running ‘meteor show foo@local’ will always show the local version
(useful for version-less local packages).
- Simplify the interface. Instead of various ‘show-*’ flags, we only have one: show-all.
By default, we only show the top 5 official (non-prerelease) unmigrated versions of a
package (+ local version, if applicable). This can be overridden with ‘show-all’, and we
let the user know that more versions are available. For releases, ‘show-all’ will show
non-recommended releases.
- Display publication time for non-local package versions. This makes it easier to run
‘meteor show <name>’ and see if <name> is actively maintained. For local packages,
we display the root directory (useful for large apps or running with the
LOCAL_PACKAGE_DIRS variable, for example).
- For non-local package versions, show if the version is ‘installed’ (downloaded into the
warehouse). This involved minor changes to tropohouse.js. The idea is that this should
give a pretty good clue whether the version can be added offline.
- Show version dependencies. This should help the user understand, track down and
debug constraint solver failures.
- Do not show version architectures except in —ejson mode.
- Allow an ‘—ejson’ flag to get the output in EJSON format. That should make scripting
easier. (As a bonus, for release versions, the EJSON output acts as a nice template
for the release configuration file.)
The search command now does the following:
- Interacts with local package versions. Specifically, local versions override equivalent
server versions. Also, ‘search’ works on local packages (so, for example,
‘meteor search troposphere’ inside the package server app will give you the troposphere
package).
- Allows an ‘—ejson’ flag to get the outout in EJSON format.
Minor changes to some minor testing infrastructure:
- A new skeleton package, package-for-show. Its versions contain different
values for various metadata, so we can test that metadata comes from
the right version.
- In several places, replace the pattern of copying around
package.js files with using the replace function on a placeholder
string. (Mostly, as applied to package versions).
This is based on these hackpads: https://mdg.hackpad.com/Showing-Package-Metadata-HdGo3Lzx3hR
and https://mdg.hackpad.com/Meteor-Search-Output-1xxEzrAK9YU.
Summary:
I recently learned that `curl <url> | tar zx` works just as well as
`curl <url> | gzip -d | tar x`.
I'm also hoping to test out the new Phabricator.
Test Plan: Regenerating the dev bundle on Jenkins.
Reviewers: glasser
Reviewed By: glasser
Differential Revision: https://phabricator.meteor.io/D7
