Saves 50MB from the extracted size of the dev_bundle/lib/node_modules
directory, previously 262MB. The entire dev bundle is 332MB extracted, for
perspective.
More importantly, since the `phantomjs` binary is not very compressible,
this change reduces the *compressed* size of the dev bundle from 71MB to
54MB, a 24% savings.
Closes#6905.
Note there are a few use cases I can think of we want to worry about:
`meteor run` -- both should be "development"
`meteor run --production` - both should be "production"
`NODE_ENV=production meteor run` - as above
`NODE_ENV=development meteor run --production` - `--production` should win
`meteor test` - NODE_ENV should be "development", buildMode should be "test"
`NODE_ENV=production meteor test" - NODE_ENV should be "production", buildMode should be "test"
Bump up the crashCount reset delay from 3 seconds to 8 seconds.
If the delay is smaller than app start-up time, then an app that
crashes at start-up will be treated as an app that crashed while
running and will be automatically restarted, and this will lead to
an infinite loop of restarting. Making the delay longer just increases
the time right after app start where a crash counts towards the max of
three restarts in a row. For example, if we upped the delay to 60
seconds, then an app that crashed in its first minute would restart but
gain a crashCount of 1, and if there were two more crashes within the
first minute of running (without another crash *not* within the first
minute to reset the counter), the app would fail to automatically
restart.
This whole mechanism is a little janky and was written way way back.
The number 3 was previously 2, but app start-up got a little bit slower.
Hopefully the number 8 will last us until this code is replaced.
writeSiteArchive already supported rebuilding in place (rather than
creating a new build directory and moving it into place; see comments
at top of builder.js), but it was not used and didn't work:
* run-app.js only passed previousBuilders to the bundler in the case
of a client-only refresh, in which case it also passed
hasCachedBundle, bypassing writeSiteArchive altogether.
* writeSiteArchive's use of previousBuilders seemingly didn't work,
because the site archive itself was never written in place, so
trying to write the targets "in place" into a brand-new build
directory didn't make sense (and threw an error).
With this change, previousBuilders are kept across all rebuilds
(not just client-only refreshes), which enables efficient, in-place
building (except on Windows, where in-place building has never been
supported), and writeSiteArchive is fixed to write the site archive
in place as well.
Previously, we would generate reports on
"Selecting Package Versions" and "Rebuild App".
- Instead of just profiling constraint solving, profile the entire
process of preparing the project via ProjectContext, by giving
each public function that "advances the stage" a Profile.run
(typically prepareProjectForBuild).
- Improve profiler output to better distinguish multiple runs
- Distinguish "Build App" and "Rebuild App"
- Instrument lots of calls that weren't instrumented before
This command builds the app with a different directory for
`.meteor/local`, including built packages and the app database. This
allows running `meteor test-app` and `meteor test` in parallel
for a given app, with DB isolation.
Also, we've changed how test driver packages work (as used for
`meteor test-packages`, like "test-in-browser"). Instead of automatically
running tests when they load, they export a `runTests` function that
you should call when you're ready to run tests.
When running `meteor test-app` or `meteor test-packages` a new additional
last line of code is added that calls `Meteor.startup(...runTests()...)`
TODO:
* Implement `testOnly` packages. The current pattern of reading a global
from `package.js` won't work for published packages, which are stored
as metadata, not code.
* Let you choose a test driver package as an argument to `meteor test-app`
* Demonstrate that a Mocha test and driver package are possible to write.
* Expose Meteor.isTest, Meteor.isIntegrationTest, Meteor.isUnitTest
* Implement `meteor test-app --unit` which only loads test files
* `meteor test-app` should load ALL *.tests?.* files, including ones
inside imports/ directories
The comments for inBareFiber claim that it's for times when you don't want
to inherit the dynamic environment variables of the current Fiber, but
none of the call sites actually relied on this behavior. Still, it may be
worth noting that async functions automatically (and cheaply) inherit the
calling Fiber's dynamics, which is virtually always what you want.
Any code that has access to a Future object also has the capability of
calling its .return method. Promise objects, by contrast, can only be
resolved or rejected by the creator of the Promise (or any code granted
access to the special resolve and/or reject functions, which are not
simply methods of the Promise object). The run-app.js file contains a lot
of code that used to assume a Future could be resolved by anyone, which is
why the _{make,resolve}Promise methods were necessary.
For this reason, replacing Future with Promise in these two files seemed
tricky and worth attempting first, before spending time converting easier
files.
One big reason we need this is that the text format doesn't work on Windows
because of line endings. We could just replace the line endings based on
platform, but this seemed better overall.
Also, make sure to escape entities in HTML error page
Since 87b11bd we were treating client-only refreshes of the initial
server build as if they were initial builds, and not resetting the
project context. This meant among other things that local packages
weren't being rebuilt, which led to #5074 (but also would have led to a
whole bunch of other problems).
Fixes#5074.
- Refactored code in tools/cordova and introduced CordovaBuilder and
CordovaRunTarget classes
- CordovaRunner now builds and runs the project as part of the main
runner loop
- Some code cleanup and ES2015 conversions
