The release-1.4.2.7 branch was begun from release-1.4.2.6, which has
fallen behind the master branch since release-1.4.3 landed.
To avoid conflicts when merging release-1.4.2.7 into master, I published
the official METEOR@1.4.2.7 release tag, then merged master into
release-1.4.2.7, and will soon (if the tests pass) merge release-1.4.2.7
back into master, putting master back in its 1.4.3 state, except with the
release-1.4.2.7 history included.
This reverts commit be0c8c3ee0.
Although we thought the upgrade from npm 3.10.9 to 4.1.2 was worthwhile
and safe, this breaking change proved problematic:
https://github.com/npm/npm/blob/latest/CHANGELOG.md#no-more-partial-shrinkwraps-breaking
Specifically, if a Meteor package uses `Npm.depends`, and does not yet
have an `.npm/package/npm-shrinkwrap.json` file, Meteor will create a
partial shrinkwrap file in order to install npm dependencies, but (with
the changes in npm@4) transitive dependencies of the package will no
longer be installed.
Upgrading npm to a new major version was probably too much of a change for
a 1.4.2.x release, anyway, so we're reverting it for 1.4.2.7.
In case you can't wait for 1.4.2.7, you can "fix" this problem for
previous versions of Meteor by running
meteor npm install --global npm@3.10.9
You can test that this downgrade worked by running
meteor npm version
This still indicates a potentially breaking change, but not a drastic
overhaul. I think people are going to hit constraint solver issues because
of this bump, and I don't want the change to seem more significant than it
really is.
* Adjusted query string array representation to remove indices.
* Increased major version since the new _encodeParams() result is not backwards compatiable.
In testing for #7715, I discovered that the v2.2 Graph API endpoint was still in use in the `facebook` package which was due to sunset on 2017-03-25.
See Facebook Graph API Changelog here:
https://developers.facebook.com/docs/apps/changelog
When a Graph API endpoint is sunset, it (is claimed) to automatically turn over to the next more recent version, in this case v2.3.
v2.3 has a breaking-change over v2.2, notably listed in "Changes from v2.2 to v2.3":
> [Oauth Access Token] Format - The response format of https://www.facebook.com/v2.3/oauth/access_token returned when you exchange a code for an access_token now return valid JSON instead of being URL encoded. The new format of this response is {"access_token": {TOKEN}, "token_type":{TYPE}, "expires_in":{TIME}}. We made this update to be compliant with section 5.1 of RFC 6749.
This change updates both Graph APIs to v2.8 which has LTS until "At least October 2018".
Inspired by analysis from @danstiner:
https://github.com/meteor/meteor/issues/8225#issuecomment-275044900Fixes#8225, as well as the tests I added in 672c4f338a.
I changed the name of the .meteor-portable file to .meteor-portable-1.json
in order to invalidate previous .meteor-portable files. This naming scheme
will be more sustainable, because we can keep incrementing the version
number whenever we change this logic.
Implicit empty stub CSS modules added in addStylesheet in
compiler-plugin.js were being overwritten with actual CSS module code,
thanks to logic intended to support replacing package.json stubs with
their actual contents.
The meaning of "implicit" is somewhat overloaded: for package.json
modules, it means the module is a minimal stub (just the "name",
"version", and "main"/"browser" fields) that should be replaced if ever
explicitly imported. For empty stub CSS modules, it means the module
should yield to any actual modules added via addJavaScript.
