We can revisit this conversion if it turns out anyone really wants to use
@import rules in CSS files instead of using something like LESS.
Part of #6037.
- We don't want to do a bunch of parsing *per comparison* when sorting
a list of package version strings. package-version-parser's `compare`
(and server's `compare`, which it uses) both accept either a string
or a parsed record. By parsing explicitly with memoization, we avoid
a super-linear blow-up in the amount of parsing. This'll save someone
half a second, at least.
- Adjust profiling hooks and messages
- Expose `Profile` to isopackets
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");
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
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
```
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)
This ensures paths embedded in source maps for meteor/tools/ files don't
include directories outside the meteor directory, which makes navigating
the directory tree in node-inspector considerably easier.
