This method appears to be causing large spikes in memory consumption on
Circle CI during the `meteor --get-ready` preparation step, which often
leads to the test process being killed.
Also added a call in IsopackCache#_loadLocalPackage for good measure.
We're now calling requestGarbageCollection pretty frequently when
we run Node with --expose-gc, but that currently only happens during
Circle CI tests, so I don't think we need to implement the improvements
suggested in tools/utils/gc.js, yet.
Previously: 35f488e140, f6df21ff1e
To deal with individual flaky tests, we often just re-run the entire test
suite, which feels like an enormous waste of shared computing resources.
This change automatically re-runs individual failed tests as many as two
more times, and considers the test successful if any of those attempts
succeeds.
cc @abernix @hwillson et al.
This package is required to be ran with `--production` in order to for
it to accurately use data from the minifier which is only provided when
emulating or actually in production. The additional work required in
this mode is too costly to run during normal development as the
minification process (provided by UglifyJS, one of the fastest
minifiers) is still quite slow.
Once added, this package will display a sundial chart showing the weight
of the modules included in the application, in the web-browser, on top
of your existing application.
While maybe not the best final product, it's certainly something we can
iterate on and improve.
This package should be removed before bundling/deploying for production.
Now that dynamic modules are part of the manifest that determines which
files are served over HTTP, I'm a bit paranoid about them somehow ending
up as <script> tags in the initial HTML of the application.
This commit adds another safety measure to prevent that, just in case the
boilerplate-generator package for some reason fails to skip items whose
.path starts with "dynamic/" (see my previous commit).
This allows fetching the compiled code of dynamic modules via HTTP,
without generating <script> tags for those resources in the intial
boilerplate HTML of the application.
The URL for a dynamic module should be formed by taking its absolute
module identifier, prepending "/dynamic" and appending "?hash=<version>".
Appropriate version hashes can be obtained from the tree exported by the
meteor/dynamic-import/dynamic-versions.js module, though the hashes are
used only for cache busting, so they could be anything at all.
A good place to do this fetching would be the meteorInstall.fetch
callback, as defined (for example) in meteor/dynamic-import/client.js.
That implementation still uses a WebSocket rather than HTTP, but this
commit will allow us to experiment with HTTP in the future.
Because the code returned for these dynamic modules is wrapped as an
anonymous function expression, you'll need to fetch them using an
XMLHttpRequest, the HTTP fetch() function, or some similar utility, rather
than using a <script> tag, because executing the unmodified code as JS
will likely throw a syntax error.
Since it's relatively easy to remove/replace the meteor-base package, this
should keep dynamic-import optional in principle, but also make sure it's
installed in most apps without need for `meteor add dynamic-import`.
I also considered implying the dynamic-import package from the ecmascript
package, but that would have made it much harder to opt out, and created
some nasty circular dependency problems.
Partially reverts commit 8364f81344.
This commit was causing self-test failures like the following:
While selecting package versions:
error: unknown package in top-level dependencies: dynamic-import
I suspect these tests won't work until the dynamic-import package is
published with a non-prerelease version.
It's tempting to make the ecmascript package api.imply("dynamic-import"),
but the dynamic-import package depends on the ddp package, which depends
heavily on the ecmascript package, and I'm not sure how best to break that
dependency cycle.
* Update Contributing.md.
Various changes and cleanups to the Contributing information but primarily, remove the team mentions part of "Need help with your pull request?" (which don't work unless you're a member of the GitHub org). In general, contributors can get ahold of the correct person(s).
/cc @hwillson
* Update Contributing.md
* Added a small note explaining how to get dev_bundle changes published.
* Fixed grammar errors with 's; Updated @meteor/platform mention.
* Removed @meteor/platform suggestion since it can only be used by team members.
* Remove nested properties from upsert selector document
Fixes https://github.com/meteor/meteor/issues/8631
* Fix upserts that include _id in the selector
* Incorporate PR review requests.
