1a036553 in 1.4.4.2 expanded on the HTTP error checking added by 30aec9f in
1.4.2. Neither of these changes were aware that discoverGalaxy invokes
httpHelpers.request with json:true, resulting in a `body` that is a parsed JSON
object rather than a string or Buffer. Before 1.4.4.2, this had no consequences
because body.length is undefined and `undefined < 90` is false, but the change
to Buffer.byteLength actually made the condition true.
It's safe to not check length in the JSON case because a truncated JSON object
is not legal JSON (unless the truncation just drops trailing whitespace, in
white case that's OK).
I check for both string and Buffer because some calls to this function pass in
an encoding option. Buffer.byteLength works with both types.
In the ongoing struggle with Circle CI-specific test failures, the
preparatory `meteor --get-ready` has been a consistent point of failure,
before any real tests have the chance to run.
Using a lighter-weight command (meteor --help) that still does most of
what --get-ready did seems worth a try, though it might just defer
memory-intensive work until later, so we'll have to see what happens.
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.
Windows began suffering from cryptic ENOTEMPTY and EPERM errors between
1.5-beta.20 and 1.5-rc.0. After a tricky `git bisect` adventure, I tracked
the problem down to my commit b6694b2f5d,
which caused dynamic modules to be written more than once by the bundler.
Though I don't understand exactly why Windows complained in this way, I'm
glad that it did, because otherwise this mistake would merely have been a
performance problem, and might not have been noticed before the release.
In the ongoing struggle with Circle CI-specific test failures, the
preparatory `meteor --get-ready` has been a consistent point of failure,
before any real tests have the chance to run.
Using a lighter-weight command (meteor --help) that still does most of
what --get-ready did seems worth a try, though it might just defer
memory-intensive work until later, so we'll have to see what happens.
No longer using a RegExp when we know what the old file wildcard path
should be, and no longer using Fiber when we can just use a Promise
callback (since all Promise callbacks run in a Fiber).
Something went wrong with 1.5-rc.2 such that publishing meteor-tool failed
with the following error on all platforms:
While publishing package build for meteor-tool:
error: Cannot override existing build
This makes no sense to me, but it necessitates another RC release. To be
clear, meteor-tool@1.5.0-rc.2 has not been successfully published on any
platform, so please don't bother trying to update to it.
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.
There was an issue where most of the visualizer was visible but the module size details displayed when hovering over a segment were hidden behind some UI elements. Setting a high z-index fixes it.
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).
