The error messages which come from UglifyJS tend to be quite cryptic, as
seen in issues like meteor/meteor#8370 or meteor/meteor#8020. The file,
line, and column are provided, however the message is garbled and the
stacktrace long and acutely harrowing. Since these errors are occurring
on automatically concatenated files, even the line number is sometimes
not helpful. Additionally, sourceMaps are not available in production
builds, intentionally. (I wasn't able to access them from
`file.getSourceMap()` or `file.sourceMap` at all.)
In addition to actually providing the name of the encapsulating file,
which provides _some_visibility, this commit implements a parser around
the UglifyJS error which detects the error and location information of
the error, seeks to the line in the concatenated source, reads the
inline filename, and provides it in the output.
Crude, but incredibly helpful in diagnosing this problem until a better
solution is reached.
@abernix Bumping the ecmascript version is apparently necessary if the
babel-compiler package has changed, presumably because ecmascript defines
a compiler plugin that uses babel-compiler. Unless the ecmascript version
has been bumped, babel-compiler changes won't appear to have any effect.
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 calls `Npm.depends` in a way that
disagrees with the contents of `.npm/package/npm-shrinkwrap.json` file,
Meteor will create a partial shrinkwrap file in order to install the
correct top-level npm dependencies, but transitive dependencies of the
package will no longer be installed.
This was fixed in Meteor 1.4.2.7 by reverting the upgrade of npm, but
Meteor 1.4.3.1 will keep npm@4.1.2 and fix the consequences.
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".
