This reverts commit 4e4e204ab0.
This commit caused a strange regression in reliability of the Windows
dynamic-import self-test, which may be an indication of a deeper problem,
so it seems safest to revert this change for now.
In case empty .meteor-portable-2.json files are written, I've added an
additional check that the cached JSON value is a boolean.
As illustrated by #9554, if a custom .babelrc plugin such as
@babel/plugin-proposal-optional-chaining imports a missing dependency such
as @babel/core, that failure causes inputFile.require to throw an
exception that looks a lot like @babel/plugin-proposal-optional-chaining
itself is missing, which can be confusing.
This change does not fix the underlying problem (the @babel/core package
still needs to be installed), but it does expose the exception so that the
developer can do something about it, rather than merely leaving the ?.
syntax uncompiled.
Here's the offending line of code:
47ce7e71c9/packages/babel-plugin-proposal-optional-chaining/src/index.js (L2)
Unfortunately, depending directly on @babel/core seems to be the policy
for Babel plugins, per this PR: https://github.com/babel/babel/pull/6778
Previously these files were written asynchronously in an attempt to
improve performance, since the success of the write is not critical.
While I stand by my claim that it's acceptable for these writes to fail, I
noticed recently that the async write was failing very often (resulting in
an empty .meteor-portable-2.json file). Switching to sync semantics
eliminated that problem with no noticeable loss of performance. In fact,
overall performance is likely better because of the future work saved by a
successful write.
In an attempt to fix#9552, recursively scan child directories of
directories that start with '@' characters, rather than treating the
parent directory as a potential npm package.
Also, ignore directories that start with a '.' character, such as the
common node_modules/.bin directory.
Previously, the async fallback was only used in case of ENOTEMPTY errors,
but Windows appears to throw temporary EPERM errors as well. If the errors
are actually robust/non-temporary, the async version will fail, too.
Should help with #9540.
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`).
