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.
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.
* Adjust test filename RegExps to match Meteor guide. Fixes#9332.
* Adjusted help text for --drive-package on meteor test.
* Add integration tests for `meteor test` eager file loading.
* Fix typo in selftest.forbid comment.
* Improve test file eager load integration test coverage and clarity.
* Update the default CSS parsing/combining/minifying tools
The `minifier-css` package is currently using outdated
(and abandoned) npm packages (`css-parse` and `css-stringify`),
as part of its parsing/minification process. This commit
replaces those packages with the robust, modern and maintained
`postcss` package.
* Adjust CSS source file fallback value
* Self test adjustments and cleanup
* Disable sourcesContent generation by postcss
The `standard-minifier-css` package is already associating
source content with the source map, so we don't need to
do this twice.
* Add History.md entry covering backwards compatibility details
* Bump major version due to backwards compatibility breaking changes
* Bump minor versions
* Code review changes (boolean formatting, concat to spread)
Fixes an issue preventing the installation of scoped Cordova
packages. For example,
`meteor add cordova:@somescope/some-cordova-plugin@1.0.0`
will now work properly.
Fixes https://github.com/meteor/meteor/issues/7336.
The single file which represented the bulk of the `meteor self-test`
functionality had got a bit heavy and it stood to benefit from some
dissemination.
I embarked on this change originally when looking into replacing
PhantomJS with Chrome Headless (and a new `ChromeClient` class) within
self-test. Unfortunately, I didn't have time to take this the last
step of actually implementing Chrome, but this should hopefully
facilitate that change in the future by providing what I believe to be
better compartmentalization of this logic.
I apologize for the (likely) difficulty of reviewing this commit. Due
to heavy intertwining of existing code it was hard to arrange these
changes in an easy-to-review manner. I believe a reviewer will
find that it's mainly copy and pasting into different files and
careful adjusting of those files (new) module dependencies.
The changes made in #9213 were seemingly innocent, but when merging
I missed the fact that the 'cordova-lib' package bump was done to a new
entry on the 'dev bundle', rather than on the
`CORDOVA_DEV_BUNDLE_VERSIONS` in tools/cordova/index.js which, as of
meteor/meteor#8976, is responsible for auto-installing Cordova when it
is used rather than including it in the pre-packaged 'dev bundle'.
That mistake was fixed with 958c44ff1b and
d6adc1b3a9, but not before it caused the
Cordova tests to falsely pass on the PR since it was functionally still
testing the previous version of Cordova, 7.0.0.
Unfortunately, one of the changes in the 7.1.0 was the deprecation of an
API we use within Meteor: the `raw` API on `cordova_lib`. Luckily, as
seen on the following commit, that change was merely a re-organizational
commit and still provides us access to that API by simply removing
the `raw.` segment and accessing the various methods directly:
90b6857f4d
Never saw that deprecation message, but we certainly saw the failure in
CI: https://circleci.com/gh/meteor/meteor/10412.
With any luck, this commit/PR will fix the problem.
It's still possible to publish packages for different platforms by using
the `meteor publish-for-arch` command, though it's become increasingly
difficult to offer compatible versions for every circumstance due to the
wide matrix of Node.js ABI versions. This makes it unlikely that
a package built on the build farm will be appropriate for the
application which the package is consumed by, substantially reducing the
overall value of rather expensive infrastructure.
Since Meteor 1.4, and as part of the jump from Node 0.10 to Node 4,
Meteor introduced the capability to compile binary dependencies at the
time that a package is installed. Additionally, many Node.js packages
are already pre-compiled in a much more effective and wide-spread nature
for the entire JavaScript ecosystem using tools like `node-pre-gyp`.
cc @benjamn.
I think I just typo-ed that patch version right before I committed it.
It certainly should have been 7.1.0. :(
Ref: https://github.com/meteor/meteor/pull/9213
cc @skirunman.
While 'cordova-lib' used to live in 'dev-bundle-tool-package.js' where
it was pre-bundled into the "dev bundle", that is no longer the case.
It is now automatically installed, on demand, when Cordova is used.
This follows up on meteor/meteor#9213, which added it back to the
'dev-bundle-tool-package.js' and updates it in the new location.
Ref: https://github.com/meteor/meteor/pull/9213
Ref: 073f2410a6
cc @skirunman.
Several years ago, before all major browsers supported source maps, we
felt it was important to provide line number information in generated
files using end-of-line comments like "// 123\n".
Adding all these comments was always slower than leaving the code
unmodified, and recently they have begun interacting badly with certain
newer ECMAScript syntax, such as multi-line template strings (#9160).
Since source maps are well supported in most browsers that developers are
likely to be using for development, and the line number comments are now
causing substantive problems beyond the performance cost, I think it's
time we stopped using them once and for all.
Fixes#9160.
