- Return type of onMigrate callback should be an array.
- onMigrate callback can be invoked many times until all components
are ready to migrate.
- DDP negotiation failures should always migrate immediately.
Whenever you're looking at a stack trace generated by the command-line
tool, you see tons and tons of useless stack frames for withValue,
enterJob, and/or capture.
Each of these function calls has its own try-finally block, which is
probably the real reason this pattern is slow, though the excess of
unnecessary stack frames is subjectively gross as well.
Initial build times for the `meteor create --full` app on my machine are
about 4.4 seconds with Meteor 1.8, and just 2.8 seconds after this change,
which is a nice 36% improvement. Rebuild times are not noticeably
different, however.
Looking to the future, flattening this function call pyramid should make
it easier to introduce non-Fiber-based async/await into the buildmessage
system, so that we can start properly propagating promises up the stack.
https://github.com/meteor/meteor/issues/10112#issuecomment-428646872
Further down in the mergeCss function, when we call CssTools.stringifyCss,
we pass the following option:
// don't try to read the referenced sourcemaps from the input
inputSourcemaps: false
Apparently this isn't enough to avoid reading inline source maps from the
input file, so we should be a bit more aggressive about preventing postcss
from picking up inline source maps.
This change mostly affects .css files imported from node_modules, and
possibly raw .css files in the application that happen to have inline
sourceMappingURL= comments. For CSS output from compiler plugins like LESS
and SCSS, we have a totally different mechanism of handling source maps,
namely file.getSourceMap().
Should fix#10112.
As reported by @mariusrak here:
https://github.com/meteor/meteor/issues/10220#issuecomment-425244894
Only errors thrown by @babel/parser have the e.loc property. Other errors
thrown by Babel transforms do not have e.loc, but do (usually) have line
number information embedded in e.message. Either way, it's better to use
inputFile.error than to throw the error, since throwing here crashes the
build process.
Should resolve#10233, reported by @klaussner.
Previously, if a compiler plugin called inputFile.addJavaScript multiple
times with different { path } strings, Meteor would allow importing all of
those modules at once by importing the original source module identifier,
by synthesizing a new source module containing a series of re-exports for
each of the generated modules.
Preserving this behavior is important for backwards compatibility, since
some compiler plugins still generate files like "module.ext.js" given an
input file named "module.ext", so Meteor tries to make those modules
interchangeable/synonymous.
However, if the compiler plugin explicitly calls inputFile.addJavaScript
with the original source path, then it would be a mistake to modify the
contents of that module, so Meteor will now leave the contents of that
explicit source module unmodified, rather than using it as a catch-all way
to import other generated modules.
These deprecation warnings were introduced in mongodb@3.1.2:
https://github.com/mongodb/node-mongodb-native/commit/a5d0f1d7e1
Fortunately, the deprecated Collection methods still work, and the
deprecation relies on Node's require("util").deprecate API, which can be
silenced permanently for a given function by temporarily setting
`process.noDeprecation = true` while defining the function:
https://github.com/nodejs/node/blob/2ae98ce7cb/lib/internal/util.js#L23-L29
Fixing #10174 by updating mongodb seems more important than reverting the
update to silence these harmless deprecation warnings (which, it bears
repeating, were introduced in a patch update).
Thanks to @klaussner for raising this concern!
