Currently, three 'dynamic import' tests exist in the self-test suite:
* dynamic import(...) in development
* dynamic import(...) in production
* dynamic import(...) with cache
These tests take quite some time to run; each test takes ~5 minutes.
While it's great to test them in a faster environment (Unix), which
Meteor will continue to do, the overall value of the three separate
tests is not as great in a slower testing environment, like Windows.
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.
AppVeyor does provide us quite a bit of value at no cost since we're
open-source software, but with only a single container at our disposal
under that plan, our build queue is often maxed-out for hours.
Since most Meteor developers are using 64-bit platforms, the 64-bit
tests provide the most value. Meteor doesn't have much (if any?) in the
way of 32-bit/64-bit exceptions so any functionality difference would be
at the OS level. Some day, we might bring this back.
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.
* Add test for sorting with falsey selector
Falsy selectors should result in empty result and sorting shouldn't blow up.
* Protect sorter from falsey selectors
* Handle overridden _.template settings in boilerplate-generator
When `underscore`'s default `_.template` settings are overridden
using `_.templateSettings` in an application, this can adversely
affect the `_.template` calls used by the `boilerplate-generator`
to render an application's initial HTML template. These changes
make sure the `boilerplate-generator` is overridding any
defined `_.templateSettings` with its own verified to work
settings.
Fixes#9149.
* Add comment explaining additional _.template config override
* Handle overridden _.templateSettings with the cordova boilerplate
* Remove underscore use wherever possible
* Change incorrect implementation of an "empty" manifest.
This test was trying to imply an empty manifest by using an empty
associative array (hash), whereas a manifest is only ever an array
of hashes (as per the bundler code). Therefore, an empty manifest
should be an array with no items.
This is to fix the failure seen in https://travis-ci.org/meteor/meteor/builds/291857783?utm_source=github_status&utm_medium=notification
because of @hwillson's changes in 9aee811a4b.
Refs: meteor/meteor#9250.
* Make underscore replacement code more defensive
`_.map` handles a falsy input value, whereas `Array.prototype.map`
(obivously) does not. While not likely common practice, it's
possible falsy values are being passed into the boilerplate
generator, for elements like `js`, `css`, etc. These changes
replicate `_.map`'s handling of incoming falsy values by
converting them to an empty array.
* Update Facebook OAuth app config steps
Facebook has updated their application developer portal, so the
steps for creating a Facebook OAuth app have changed. This commit
updates the steps shown as part of the `facebook-config-ui`
setup process, to line up with Facebook's new dev portal.
Fixes#8867.
* Capitalize CAPTCHA.
Nit: Capitalized CAPTCHA since it's an acronym.
* Bump facebook-config-ui package version to 1.0.1.
The `installPath` property was always essentially an absolute module
identifier that was simply missing the leading '/' character, so this
commit acknowledges that role by renaming the property to `absModuleId`
and adding the leading slash.