Note that eee519ad58 greatly reduced the
TIMEOUT_SCALE_FACTOR for Circle CI tests, which likely caused some tests
to time out more often, so these additional timeouts are really just a way
of re-bumping individual timeouts, which arguably leaves the test suite in
a better overall state of health.
This restores the behavior of 8c70716954 by
default, with the option of disabling the prioritized file watching system
by setting METEOR_WATCH_PRIORITIZE_CHANGED explicitly to "false".
The self-tests where the environment variable is explicitly set form a
nice to-do list of tests that should be improved to be more robust to cope
with differences in file watcher timing.
Helps with #8648 and similar issues.
Although I think 8c70716954 is a good idea
in practice, it altered the timing of self-tests enough to cause a number
of failures, so for now that behavior will be gated behind the environment
variable METEOR_WATCH_PRIORITIZE_CHANGED.
This drastically reduces the number of open file descriptors by not
preemptively acquiring a file descriptor for every watched file.
The downside is that the first time you edit a particular file, you may
have to wait up to DEFAULT_POLLING_INTERVAL milliseconds before Meteor
notices the change. The upside is that changes will be detected
instantaneously for that file in the future, even after restart.
If holding open too many file descriptors is indeed a contributing factor
to issues such as #8648, then this change should go a long way towards
mitigating those problems.
cc @abernix @hwillson
Render callbacks can now inject HTML content into multiple different
elements, and may also append content to the <head> or <body> elements, on
both the client and the server.
This new API was inspired by trying to use the styled-components npm
package on the server, which involves not only rendering and injecting
static HTML somewhere in the <body>, but also appending the resulting
<style> tag(s) into the <head>:
import { onPageLoad } from "meteor/server-render";
import { renderToString } from "react-dom/server";
import { ServerStyleSheet } from "styled-components";
onPageLoad(sink => {
const sheet = new ServerStyleSheet();
const html = renderToString(sheet.collectStyles(
<App location={sink.request.url} />
));
sink.renderIntoElementById("app", html);
sink.appendToHead(sheet.getStyleTags());
});
Note that the server-render package now exports an onPageLoad function,
rather than the old renderIntoElementById function. The functionality of
renderIntoElementById is now exposed by the {Client,Server}Sink API.
I say the client-side version of this API is 'isomorphish' to the
server-side version, because ClientSink methods can accept DOM nodes in
addition to raw HTML strings, whereas DOM nodes don't really make sense on
the server.
Meteor 1.5.1 will pin version 1.4.x of the accounts-password package, so
Meteor 1.6 only needs to use a different (greater) minor version.
Related: 0ad123db5b
If a package has a semantic (x.y.z) version in npm-shrinkwrap.json, npm
appears to install it always from the npm registry, rather than the
original tarball URL (uncommon but used by the less and stylus Meteor
packages, among others).
This was preventing `node-gyp` from installing the Node header files on
Windows and was the reason that `minimatch` was not being found, as seen
in https://github.com/meteor/meteor/pull/8831.
The `minimatch` module was present, but it was just in `dev_bundle/lib`,
not in `dev_bundle/lib/node_modules/npm/node_modules`.
This expecation may have been expected from older versions of npm but is
no longer the case. This replicates the behavior of the Unix
`generate_dev_bundle.sh` script, which also does not nest `node-gyp`.
/cc @benjamn
Based on this warning:
npm ERR! As of npm@5, the npm cache self-heals from corruption issues and
npm ERR! data extracted from the cache is guaranteed to be valid. If you
npm ERR! want to make sure everything is consistent, use 'npm cache
npm ERR! verify' instead.
npm ERR!
npm ERR! If you're sure you want to delete the entire cache, rerun this
npm ERR! command with --force.
