This package contains some of the most fragile tests in the entire
codebase, in large part because the author did not account for the
nondeterminism of JS timers across platforms and test runs.
As of React 16, using `ReactDOM.render` in the manner
demonstrated in the `server-render` README will cause a
React deprecation warning. Switching to `ReactDOM.hydrate`
will avoid this. From the React docs:
> Using ReactDOM.render() to hydrate a server-rendered
> container is deprecated and will be removed in React 17.
> Use hydrate() instead.
Source: https://reactjs.org/docs/react-dom.html#render
The syntax of these flags is the same as the equivalent Node.js options:
https://nodejs.org/en/docs/inspector/#command-line-options
When no port value is provided, the default is 9229.
Two notable differences:
* The flags affect the server process spawned by the parent build
process, rather than affecting the build process itself.
* The --inspect-brk flag causes the server process to pause just after
server code has loaded but before it begins to execute. This timing is
more useful than the Node.js --inspect-brk behavior, which is to pause
on the first instruction executed by the process, since that is too
early to set any useful breakpoints.
Implements https://github.com/meteor/meteor-feature-requests/issues/194.
This was preventing the proper group name from being displayed on test
group "2", though the test was still working properly.
Refs: https://github.com/meteor/meteor/pull/9190 where it was spotted.
Native file watching is notoriously unreliable on several Windows file
systems (e.g. NTFS, since network file systems have trouble supporting
change notifications).
However, disabling native file watching for all Windows developers was
probably a step too far, since it *could* work just fine, and we still
have the fs.watchFile-based safety net, which no longer hogs idle CPU
cycles for unchanged files.
You can explicitly disable native file watching and use polling instead by
setting METEOR_WATCH_FORCE_POLLING to a truthy value.
Should help with #9175.
Meteor attempts to use native file watchers to detect changes as soon as
possible, but we also employ an fs.watchFile-based safety net to detect
changes by polling, which adds reliability on platforms with poor (or
nonexistent) support for native file watching.
However, fs.watchFile tends to consume more idle CPU cycles when many
files are watched, so we use a relatively long (5000ms) polling interval
to watch files that have not yet been changed. After we detect the first
change to a file, we promote it to a much shorter (500ms) interval and
attempt to start a native file watcher.
Even if we were able to create a native file watcher using the pathwatcher
library, it may not fire notifications reliably on some file systems, so
this commit keeps polling changed files at the higher frequency, rather
than lowering the polling interval back to 5000ms.
The number of files the developer has changed by hand should never come
close to the total number of files watched by Meteor, so keeping them at
the elevated polling interval should pose no problem for idle CPU (#9175).
These errors are especially harmful because they cause files.rename to
fall back to copying rather than atomically renaming, which is both much
slower and not even remotely atomic.
