We only need version constraints on core packages in some cases. For
example, when referring to "core" package wrappers (like `npm-mongo`)
which uses an API outside the Meteor build system.
Because as @hwillson rightfully points out:
> that's what we're really exposing and `connect` themselves refer to the container that holds the defined middleware (the result of calling the `connect()` function) as a connect "app"."
As per the comment on line 653, this appears to be the best (only?) way to let users do things like set up a custom error page to catch app-rendering-time exceptions.
Apply the check for a SyntaxError indicating an incomplete command only
to the ECMAScript translation and parsing of a command and not to the
execution, following the example of Node's defaultEval function.
Fixes#8290.
This restriction was preventing the standard-minifier-css from getting
the latest updates to minifier-css. Typically, when publishing
a package outside of a release cycle, I believe we need to manually add
this constraint since `meteor publish-release` normally takes care of it
automatically, however in most cases, I don't believe this should be
(permanently) committed.
I may stand to be corrected, but will find out soon!
This was only intended to be there during the publishing of
`standard-minifier-js` as part of meteor/meteor#8414 and is normally
not necessary as part of the `meteor publish-release` process.
In order to allow for a blank `app.js` which occurs in the case of
a Meteor app using a fully-"package"-based structure with no actual
application code in the top-level. See meteor/meteor#8414 for more.
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.
* Added in Meteor.loggingOut() and related Blaze helpers.
* Switched loggingIn/loggingOut over to use ReactiveVar; More tests.
* Changed logginInOut helper name to loggingInOrOut.
@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.
