* Visually notify of uncaught exceptions breaking client tests
These changes add a global `window.onerror` event handler
to the `test-in-browser` package, to catch any previously
uncaught exceptions. When uncaught exceptions are found,
an alert box is displayed above the test results table.
This should help notify developers of hidden uncaught
exceptions that could be preventing client tests from
running.
Fixes#4979.
* Bump the test-in-browser package version
A while back we switched from running `./meteor --get-ready`, a command
that takes many minutes and sometimes runs out of memory, to just running
`./meteor --help` to prepare for self-tests.
The hope was that `./meteor --help` would fail less often, and the work
that would have been done by `./meteor --get-ready` would be spread out
through the actual tests. This helped, I think, but we've been seeing
quite a few self-test failures due to unreliable timing of the actual
tests, so I'd like to try shifting the balance back.
I'm pushing this to the branch with our patched Node 4.8.4, because
that branch should have a lower risk of segmentation faults, which may
allow `./meteor --get-ready` to succeed more often.
This is a bit of a shot in the dark, admittedly, but I want to see what
happens. 🤞
To remain the same as official Node.js releases, we need to build with
the `small-icu` ICU (International Components for Unicode) package.
For Node.js 4.x this means ICU 56.x. As found with `process.config` on
an official Node.js release.
See https://github.com/nodejs/node/wiki/Intl#configure-node-with-specific-icu-source.
This is performance-sensitive code, and I think this extra (uncached) call
to files.statOrNull could be contributing to test timeouts on Circle CI.
Follow-up to #9030.
As outlined in #3854, if `meteor --settings` points to a
directory instead of a file, an application gets caught up
in an infinite rebuild loop. Since it was assumed only a
file would be configured via `--settings`, a file watcher
is created for the specified directory, and that watcher
is then triggered ad infinitum.
These changes prevent a file watcher from being created
on a `--settings` directory.
This will make it easier to merge devel into release-1.5.2, since devel
now contains the final verison of these changes, as implemented by
@GeoffreyBooth in #9018.
Revert "Bump coffeescript package version to 1.13.0."
This reverts commit d727ad02a7.
Revert "Move coffeescript and coffeescript-test-helper packages back into core. (#8960)"
This reverts commit eb3c7dd344.
Revert "Split coffeescript package into coffeescript / coffeescript-compiler."
This reverts commit 8344cbf59d.
Revert "Instructions for how to test the coffeescript package"
This reverts commit 491cbc3bfe.
Small follow-up to #9018.
Note (especially @GeoffreyBooth): these version constraints do two things:
(1) specify a minimum version, and (2) fix the major version. In other
words, the coffeescript package should not need to be republished when we
publish new minor versions of these core packages in Meteor 1.5.2 or 1.6.
When/if we publish a new major version of these packages, the coffeescript
package can simply bump its version constraints, but that probably won't
happen any time soon. I think that's reasonable because a major version
bump suggests there are some significant changes that need to be
acknowledged by dependent packages.
If a login token is expired, or no longer valid, make sure that Meteor doesn't
just sit there at a login prompt that the user can't see.
This currently only applies if `headless` mode is enabled, though a follow-up
to this commit might consider setting `headless = true` automatically
in a CI environment using environment variables such as: `CI`, `TRAVIS`,
`JENKINS_URL`, etc., as the npm-registry-client does in a similar way.
See: https://github.com/npm/npm-registry-client/pull/129/filesFixes#8839.
The `child_process` documentation indicates that .cmd scripts (such as
the `npm.cmd` script for npm) must be started within a shell, such as
cmd.exe.
While it was tempting to switch this to use `child_process`'s `spawn`,
which supports a `shell` option, it would have required us to buffer
our own stdout/stderr output via `data` event handlers.
Ref: https://nodejs.org/api/child_process.html#child_process_spawning_bat_and_cmd_files_on_windows
This was causing problems with `npm@5`, but realistically it may not be
be necessary anymore since `npm@5` has a much smarter global,
self-healing `cacache`.
@GeoffreyBooth and I are still deciding exactly what to do with the
coffeescript package in #8960, but in the meantime I need to publish
another 1.6 beta, and I'd like to avoid publishing a beta version of
coffeescript along with it.
