The last version of stylus published did not contain a version of the
caching-compiler package that these tests now depend on, so I've removed
the extra architecture matching for the stylus package (not for less).
To fix#9528, we included more information (the target architecture) in
cache keys for files compiled by CachedCoffeeScriptCompiler. Although this
change was right and necessary, it altered the caching behavior tested by
this self-test. Specifically, .coffee files must now be recompiled for the
os.* architecture, whereas previously code compiled for web.browser could
be accidentally reused on the server.
Self-tests that are marked as "slow" are not run automatically for pull
requests, but they should be run before a release.
It was a mistake to publish the first Meteor 1.6.1 release candidate
without running these "slow" tests, as the cordova-builds test would have
caught the problem reported by @macrozone in #9521.
I've decided to remove the "slow" marker from this test, since it's
important for checking Cordova sanity, and clearly could fail.
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.
These changes are needed to get the plugin meteor-coverage working. IstanbulJS (shipped with meteor-coverage), can only generate the coverage-report for the code loaded after it's initialization. This is why the code, the plugin meteor-coverage contains, must be executed before the code is loaded, which should be tracked in the code-coverage. A suitable check I found was when a debugger isn't used, which makes it impossible to use code-coverage and the debugger at the same time. It's the only feasible condition I could come up with.
The package meteor-coverage also registers a hook of IstanbulJS which overwrites `vm.runInThisContext()` in order to start the coverage. As of now, IstanbulJS does not support overwriting `vm.Script.runInThisContext()`.
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.
