During the Meteor 1.6.1 beta period, we introduced logic to render a
<script> tag to load the SockJS library in older browsers (#9353), and so
it seemed important to run test-packages both with and without the
<script> tag, using a special query parameter appended to the app URL.
The #9353 changes were ultimately reverted before Meteor 1.6.1 was
released (see 365804218f), and Meteor 1.6.2
will take a very different approach to bundling dependencies like SockJS
for legacy browsers (#9439). As part of this approach, PhantomJS is always
considered a legacy browser, and as such provides valuable feedback on the
behavior of web.browser.legacy bundles. However, since there's nothing to
configure with regard to SockJS anymore, there's no point in running the
test-packages suite twice in PhantomJS.
In order to run these tests in a modern browser environment, we should
probably revisit the idea of running tests in headless Chrome:
https://github.com/meteor/meteor-feature-requests/issues/254
* Introduce MONGO_BIND_IP override
Introduces an environment variable (MONGO_BIND_IP) for overriding of meteor's mongod's `bind_ip` option to allow docker containers to bind on `0.0.0.0` to be able to expose mongod processs via docker's `-p 3001:3001` port bindings.
Related issue: https://serverfault.com/questions/758225/cannot-connect-to-mongodb-in-docker
Partially Related PR: https://github.com/meteor/meteor/pull/469
* Use METEOR_MONGO_BIND_IP over ambiguous MONGO_BIND_IP
Change request to use METEOR_MONGO_BIND_IP over ambiguous MONGO_BIND_IP
- This changes meteor deploy to poll the /version-status/ REST endpoint
in Galaxy for the build and deploy status of the returned version
- Also fixes up a typo in a test
- Currently only configured to use a default polling configuration
- This change also adds a flag called --no-wait which allows users to
specify that they want the deploy command to behave just as before
This could have prevented #9631 from being a problem in the first place,
and feels like the right thing to do, considering the number of cases
we've seen of people accidentally including babel-preset-meteor in their
.babelrc files.
As usual, we have to bump the ecmascript version as well, so that the
compiler plugin will be rebuilt.
Console.isInteractive() will be false during our Circle CI test runs,
since we set the METEOR_HEADLESS environment variable, so this change
should help prevent spurious test failures like these:
https://circleci.com/gh/meteor/meteor/15305.
This should help with analyzing how much time computeJsOutputFilesMap
spends scanning imports within individual packages (scanImports) versus
resolving cross-package imports (scanMissingModules).
In the conversion to ECMAScript classes in
https://github.com/meteor/meteor/commit/6fcf190bb489db19, it appears that
JSDoc `@method`, `@instance` and `@memberof` declarations were already
in place for the (outgoing) `Mongo.Collection.prototype.{foo}` expressions,
with the exception of `upsert`. The omission caused docs generation failure
with the new ES syntax since, presumably, it was less possible to be inferred
from the `MCp*` notation.
Additionally, this changes the casing of `@memberOf` to `@memberof`,
mainly because:
* The JSDocs use this notation.
* The data JSON outputted by JSDoc lowercases property keys, including
cases where `memberOf` was capitalized, making it less clear that
there is a 1:1 mapping.
* My editor refuses to syntax-highlight jsdoc declarations with [A-Z],
possilby because of the above reasons.
Changes:
* Use ECMAScript class and arrow function syntax for Tracker.Computation
and Tracker.Dependency.
* Remove the deprecated.js file (no more Deps, Tracker.depend, or
Tracker-related Meteor.* APIs).
Should fix#9598, thanks to @abernix's diagnosis of the problem:
https://github.com/meteor/meteor/issues/9598#issuecomment-361570289
My later comment in that issue thread is not accurate, since the Babel
wrapNativeSuper helper already pulls in the core-js Reflect.construct
polyfill. Instead, the root of the problem really seems to be Babel's
generation of an unguarded _typeof(Reflect) expression.
146c11425b
The recent 7.0.0-beta.39 versions of some Babel dependencies snuck into
the last dev_bundle/lib/node_modules build, due to using ^7.0.0-beta.38
version constraints in babel-preset-meteor/package.json, even though
meteor-babel exactly pins the version of babel-preset-meteor.
After I rebuild the dev bundle, this change should fix the current test
failures on the devel branch.
This reverts commit dfc0702558.
We've seen some odd test failures (e.g. `passwords - tokens`) and trouble
updating from 1.6.1 to 1.6.2-beta.3 (easily solved with `meteor reset`,
but also worth investigating), so I think we should keep working on the
Mongo 3.6 upgrade in a PR, rather than running all of our tests against
a devel branch that includes Mongo 3.6.
cc @abernix @hwillson
The change made in a30f42c4ac switched
from CommonJS to ECMAScript export notation.
It seems JSDoc isn't smart enough to make the same association as it did with
the previous notation as it does for an anon. function expression `export`-ed
as a `const`ant. We could annotate this with `@function check`, but it seems
reasonable to just export a function declaration directly, which JSDoc will
understand.
This, along with ababb18aef, corrects the
failure of docs generation originally discovered in:
8f7ceb5de5.
Refs: https://github.com/meteor/meteor/pull/9593
It's nice to match versions, but we couldn't bump the minor version of the
Meteor jquery package without breaking compatibility with the current Meteor
release (1.6.1), since jquery is a core package.
The next Meteor release (either 1.6.1.1 or 1.6.2) will either use the new
1.12.1 version or (ideally) jquery will no longer be a core package, and
thus will not be constrained by the release.
Related: #9605
Note that you can run `meteor npm install jquery` (any version) in your
top-level application directory, and the meteor/jquery package will use
that version instead of 1.12.1.
The changes made in 8bbfd531c1 prevent
JSDoc (used to generate docs for https://docs.meteor.com via the
https://github.com/meteor/docs repository) from associating the
convenience methods which are exposed on the `Meteor` namespace
(e.g. `Meteor.call`, `Meteor.apply`, `Meteor.reconnect,` etc.) as they are
being identified as members of the `Connection` class. While this is
techincally true, and all of these are also available on
`Meteor.connection` (e.g. `Meteor.connection.status`), we have
historically exposed them in the docs using their (preferred) `Meteor.*`
aliases.
Hopefully, this at least partially resolves
8f7ceb5de5.
This reverts commit b06a6af335, where I
attempted to allow `Mongo.Collection` to be subclassed by non-native class
syntax by implementing static `call` and `apply` methods.
As the reproduction in #9595 demonstrates, in order to subclass
`Mongo.Collection` properly given this trick, one would need to override
not only the `constructor` method but also the `init` method that the
`Mongo.Collection` base class calls. Since this implicit expectation is
too much to ask of new subclassing code, let alone existing subclassing
code, I'm afraid the only remaining option is to go back to implementing
`Mongo.Collection` as a traditional constructor function, rather than
using native `class` syntax, so that subclasses can invoke the constructor
using `Function.prototype.{call,apply}` as they've always done.
