PR #9343 changed the return type of Boilerplate#toHTML from String to
Stream, which is likely to break existing code that expects a string.
In order to make the change in return type more obvious, I have renamed
the method to toHTMLStream, and I have attempted to update all call sites
appropriately. However, because this change comes in the release candidate
phase of Meteor 1.6.1 testing, it seemed important to preserve the
string-returning behavior of toHTML, with a deprecation notice.
Unless third-party code is using the Boilerplate class directly, I don't
think the toHTML method will ever be called, and we can remove it in
Meteor 1.6.2.
Thanks to @macrozone for tracking this problem down.
Fixes#9521.
This commit updates the `meteor create --full` app skeleton to use `meteortesting:mocha`
(and npm based `chai`), instead of the deprecated `practicalmeteor:mocha` package.
Clearly we haven't remembered to bump this version for some time now,
which is too bad, because it could have provided a more helpful error for
developers using an older version of Node in their non-Galaxy deployment
environments: https://github.com/meteor/meteor/issues/9470
* Prevent Tool crash when settings file contains BOM
The use of a byte order mark in a `--settings` file
crashes the Meteor Tool, when it attempts to JSON parse
the loaded settings data. Since a BOM is not required
(or recommended) when using UTF-8, this commit removes
it from the loaded settings data, before it is parsed.
Fixes#5180.
* Add PR link to History.md
* Update History.md
Since this test utilizes the `testWithAllClients` technique, which runs
the tests in various clients/browsers, it's necessary for the tests
`Sandbox` to define `clients`, otherwise the function within
`testWithAllClients` will not be executed at all. This was causing this
particular test to always return success (it was running without failure
on exactly zero clients).
Also the technique of setting `this.baseTimeout` appeared to cause
problems, likely because it overrides various other values instead of
using `waitSecs` (we don't use the `baseTimeout` technique in other
places within self-tests either).
Discovered during testing, as mentioned in
https://github.com/meteor/meteor/pull/9439#pullrequestreview-83139232.
This functionality was added in reify@0.13.3:
10c90cd0a2
The changes to modules-test-plugin/plugin.js cause files like array.arson
to mirror array.arson.js, which exercises module.makeNsSetter(true) and
relies on default exports.
This adds a memoized helper function for detecting Emacs throughout the
CLI tool and automatically resorts to "ProgressDisplayStatus" mode when
Emacs is enabled.
In my tests with both Emacs 22 and 27, this nearly doubled performance
when using Meteor from within the Emacs shell (i.e. `M-x shell`).
When sources in the `node_modules` directory are being watched
by a build plugin, if that build plugin is removed while the
Tool is running, the Tool can crash. This is because the Tool
currently see's this situation as an improbable edge case, and
purposely errors out instead of allowing the Tool to continue.
This commit adjusts the Tool to swallow this exception
thereby allowing the rebuild process to continue normally
(and avoiding a Tool crash). Given that the liklihood of this
situation happening is quite low, and the impact of allowing
the rebuild to continue is neglibile (if source files are
no longer handled by a build plugin, app developers will
notice quickly), this seems like an acceptable way forward.
Fixes#8644.
As demonstrated in https://github.com/meteor/meteor/issues/9276.
This test wouldn't have caught the regression in the previous solution
since the lack of a TTY in the `self-test` test harness caused the tests
themselves to take the path through `shell-server`'s `evaluateAndExit`
logic, which didn't use the `global` scope in the same way as the
interactive shell. That is no longer the case as of e0682c553d.
Much of the infrastructure to run "self test" tests (those which test
core functionality of the `meteor` tool itself) in PhantomJS and
BrowserStack was already in place, though the BrowserStack portion had
been disabled some time ago, though the exact reason isn't entirely
clear.
BrowserStack could play an important roll in Meteor's future as Meteor
works to ensure that the bundle delivered to the client is appropriate
for that client's capabilities, including appropriate polyfills to
implement functionality not natively available in the browser (e.g.
ECMAScript features, SockJS, etc.).
Since tests themselves already keep track of their failure, and the test
list (i.e. the `TestList` class) tracks other concepts of grouped tests,
such as "all tests", "filtered tests", etc. (like a `TestList` class
would!) I believe it makes sense for it to also maintain a collection of
"failed tests"... (in list form, of course!)
This will allow the `Run.runTest` logic to move into `run.js` file without
needing to pass back a separate `failed` variable in the event of a
failure, since that is already being tracked through the `notifyFailed`
facility.
The `meteor build --architecture` help was missing
`os.windows.x86_64`. This commit adds it in and also updates
an out of date comment in the source that referred to there
only being 3 allowed architectures.
While running the tests three times might make a lot of sence in CI
environments, it certainly slows things down in development, especially
when you've failed a test on purpose, but still have to wait for it to
run three times to get the output.
This not only implements the `--retries` flag, but also activates it in
both CircleCI and AppVeyor test suites.
As explained in the entry for the `meteor` command, the first line of each
entry in help.txt is the summary for autogenerated command lists, and thus
will not be displayed in the help for the command.
