Note that `export default` no longer modifies `module.exports`, but simply
defines `exports.default`, so these two import styles will work:
import DefaultExport from "./export-default-module.js"; // preferred
var DefaultExport = require("./export-default-module.js").default;
but this style will no longer work:
var DefaultExport = require("./export-default-module.js");
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.
The beta released with this commit (modules-beta.6) included everything on
the release-1.3 branch up to bdf64da339
("Avoid circular package.json resolution chains.").
Unfortunately, additional commits were pushed to the branch before this
commit was pushed, so the release tag release/METEOR@1.3-modules-beta.6
does not correspond to any commit in the branch history.
Rather than attempting to rewrite the branch history, I decided to amend
this commit with this explanation before pushing it.
To see exactly what was released with the sixth beta:
git fetch --tags
git log release/METEOR@1.3-modules-beta.6
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
The only reason for the files.stat in atomicallyRewriteFile (called
by Builder#write), which was taking up time comparable to write
and rename (not as much as one of those but same order of
magnitude, in the hundreds of ms total)... was for the case where we
are trying to rename a file in a way that overwrites an existing
directory. We can avoid the stat by catching this unusual case when
rename throws an error.
Background: we omit entries from the report whose time is below
a threshold (by default 1ms).
This change prevents a display like the following, where the
presence of child entries creates a "group" but the group
appears to be empty except for "other":
```
foo...........30 ms
other foo 29 ms
```
Note that for code that may or may not run in the context of a
compiler plugin, you should always test `typeof Profile` before
assuming it exists in the global environment.
METEOR_PROFILE=1 sets the threshold for displaying profiler entries
to 1ms. Previously, however, passing "0.1" or "0" would enable
profiling but use the default threshold of 100ms. With this change,
any recognizable number passed as METEOR_PROFILE will be used as
a threshold, including "0.1" and "0".
profile.js uses some "dumb" data structures and algorithms that are
N^2 or even N^3. If you experiment with adding more data to the
profile (e.g. names of files written), you'll find that the time it
takes to generate the profiler report blows up. This commit
makes the profiler usable again in that case.
* Don't create a new array in isChild(.), and compare elements
starting at the end (because early elements are more likely
to be similar)
* Swap order of entryName(.) (cheap) and isLeaf(.) (expensive)
in leafTotal(.)
Switching from "require" to "import" in the coffeescript plugin
broke our hack that keeps coffeescript from clobbering our version
of Error.prepareStackTrace, because imports are automatically
hoisted to the top of the file, and thus so are any side effects of
requiring a module.
The new fix has the tool save a copy of the correct
Error.prepareStackTrace so that any plugin that wants to unclobber
Error.prepareStackTrace can do so.
Other, fancier fixes are possible; there's a package called
stack-chain that installs a getter/setter on
Error.prepareStackTrace:
e51a7b2e0f/stack-chain.js (L136)
The linker caches files both on disk and in an in-memory LRU cache.
Because it didn't populate the in-memory cache when it hit the disk
cache, and the disk cache persists between tool runs, the in-memory
cache would typically sit empty.
This fix seems to knock 1.8s off of a 12-second rebuild time for one
app.
This allows packages to import npm packages they have not installed, with
the expectation that the app developer will provide those dependencies by
installing them into the top-level node_modules directory in the app.
For example, an app can now `npm install react` and that npm package can
be used by any package as well as by the app.
