This is a change that was necessary on the wip-upgrade-to-node-6 branch,
and it seems better to ship it sooner rather than waiting:
meteor/meteor@d823812e85
The `winston` npm package is not an ECMAScript module, but it does export
a "default" property, and this property was accidentally clobbering the
"default" property of the namespace object, thus interfering with default
import syntax:
import winston from "winston"
Specifically, the `winston` variable would end up referring to
`require("winston").default`, rather than `require("winston")`.
Nothing is lost by fixing this problem, as you can still refer to
`winston.default` if you need to access that property.
Reported by @fermuch here:
https://github.com/meteor/meteor/pull/8327#issuecomment-304721401
Fixed by this commit:
20fdd10d04
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.
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).
