This includes https://github.com/laverdet/node-fibers/pull/429, fixing the
CPU spikes reported and discussed here: https://github.com/meteor/meteor/pull/10527#issuecomment-567982128
Using an official fibers release rather than a GitHub URL is preferable
because it doesn't require building fibers from source when deploying a
Meteor app to production, and also doesn't rely on GitHub being
operational, though of course it does rely on other networked services
like npm.
We haven't always updated this minimum version when we've changed the
Node.js version bundled with Meteor, which is fine because most deployment
strategies (including Galaxy) use the right version of Node.js
automatically. With Meteor 1.9 and Node.js 12.14.0, however, it seems
important that we make absolutely sure new Meteor apps are not getting run
in production with an end-of-life'd version of Node.js (v8).
Apparently calling v8::Isolate::AdjustAmountOfExternalAllocatedMemory
frequently results in lots of wasted CPU cycles on garbage collection, per
discussion here: meteor/meteor#10527 (comment)
This fix was inspired by marudor/libxmljs2#22, which seems to have
addressed nodejs/node#30995.
Another project that benefitted from adjusting external allocated memory
less often: mapnik/node-mapnik#136
With Node.js 8.x nearing end-of-life status at the end of this year, and
Node.js 12 now in LTS, we think it makes sense to finalize Meteor 1.9
sooner rather than later, and continue working to take advantage of all
the great features of Node 12 in future 1.9.x releases.
As usual, the meaning of "release candidate" is that we can still fix bugs
before the final release, but there will be no new features added.
When we run 'meteor test-packages' as part of our Circle CI test rotation,
we happen to be testing the Meteor `jquery` package along with all of our
other packages, so it has a chance to define `window.jQuery` globally, so
everything seems to work.
However, if you run `test-packages` with a subset of packages that does
not include or depend on `jquery`, there will be errors in the browser
console about `jQuery` not being defined, because the `test-in-browser`
package depends on `blaze`, which implicitly depends on `jquery`.
Although the Meteor jquery package is no long a core package (and thus is
not tied to the Meteor release), it seems like a good idea to nudge folks
towards installing jquery from npm, instead of relying on the very old
version (1.12.1) residing in meteor/packages/non-core/jquery/jquery.js.
Closes#10289.
Adding native `bcrypt` to a project may require build tools be available on the system. This commit adds a note about that, and a link to the node-gyp documentation that best explains which tools to install. For more details, see this issue: https://github.com/meteor/meteor/issues/10113
Related to switching to NPM, it would be a good occasion to open up to a broader tooling ecosystem.
A big missing piece from the developer standpoint is Storybook. It's not just some nice tool, it literally changed the way we develop frontend in my company and all the companies where I've managed to introduce this magical tool.
Sadly it doesn't work correctly with Meteor, because it is based on a Webpack build. This issue haven't really been solved. We've added Storybook to Vulcan, but that's more a hack than an actual solution (basically we scrap Meteor imports + rely on Vulcan's naming convention to find package root...) so I am not personaly knowledgeable enough to help :/
Another great tool is Jest, it's way more efficient than Mocha thanks to its powerful CLI, but needs some webpack build.
