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.
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.
This reverts commit b9f0a54b39.
Though probably a good idea for the future, this change was not really
necessary for Meteor 1.6, and probably too risky for a release candidate.
The `installPath` property was always essentially an absolute module
identifier that was simply missing the leading '/' character, so this
commit acknowledges that role by renaming the property to `absModuleId`
and adding the leading slash.
Previously, if more than one module in a package tried and failed to
import the same identifier, we would record information about only the
last failed import.
This was good enough for later attempting to resolve the failed import in
other packges or the application's `node_modules` directory (a concept
known as "peer dependencies"), but it sometimes discarded information
about whether the failed imports were dynamic. In particular, if the last
recorded failed import was a dynamic import, it could accidentally render
the entire peer dependency tree dynamic.
Although it's a bit more complicated than what we did before, I believe
the simplest solution is for the ImportScanner to maintain a mapping from
failed identifiers to lists of import information objects, rather than a
single object, so that no information is lost.
The `meteor debug` command behaves like Node's `--inspect-brk` flag, in
that it attempts to pause the server before executing any server code.
However, simply passing the `--inspect-brk` flag to Node causes execution
to pause on the very first line of code, which is not good for setting any
breakpoints, because no server code has actually loaded yet.
Instead, the `meteor debug` command uses Node's `--inspect` flag to enable
debugging without an initial pause, then manually pauses at an appropriate
moment during server startup. Ideally, the pause should last until an
inspector client has been attached to the process, at which point the
developer has a chance to set any desired breakpoints, then clicks the
continue button to proceed with server startup.
The most difficult part of this process is detecting when the inspector
client has attached. Previously, the parent process listened for the child
process to print a "Debugger attached" message to STDERR, which happens as
a result of this `fprintf` call in Native C++:
7cff6e80bf/src/inspector_io.cc (L396)
However, this message was not printed in some cases, especially on Windows
(#9165), and required inter-process communication even in the ideal case.
All of that logic is gone now, thanks to this commit.
This commit takes advantage of a difference in behavior of the `debugger`
keyword depending on whether or not an inspector client is attached. When
no client is attached, the `debugger` keyword is a no-op that takes no
time (or very little time) to execute. Once a client has attached, the
`debugger` keyword triggers a breakpoint that lasts until the developer
explicitly continues execution through the client UI. Needless to say,
this makes the `debugger` keyword take longer than a no-op.
Because the `debugger` keyword does nothing until a client connects, we
can safely poll a `pause` function containing a `debugger` keyword at a
frequent interval (say, every 500ms). Once a client connects, the
`debugger` keyword will become active, pausing the server at exactly the
point we hoped. The difference is easy to detect by timing the `pause()`
function call. Once the `debugger` keyword becomes active, we stop polling
and allow server startup to continue.
Elegant!
Fixes#9165.
By my calculations, the sum of the sizes of the individual isopackets was
152MB, and the size of the combined isopacket is now just 36MB. That
remarkable difference goes to show how much duplication of transitive
dependencies was happening before this change.
That's a savings of 116MB for the (uncompressed) size of the meteor-tool
package. In Meteor 1.5.x, the meteor-tool package is about 544MB, but in
Meteor 1.6 it's considerably smaller: 373MB. In other words, this change
should reduce those sizes to 428MB (-21%) and 257MB (-31%), respectively.
This used to "work" (somewhat accidentally) before we got stricter about
which `node_modules` directories `Npm.require` can search:
971d2b1272
This commit should fix the problem with `juliancwirko:postcss` reported
here: https://github.com/meteor/meteor/issues/9094#issuecomment-331964596
Note that this only works for `Npm.require` when called during the build
process, not at application runtime. Use ordinary `require` for that.
While Babel 7 seems to work perfectly well, and the process of upgrading
has been useful, the upgrade is going to require Meteor developers to
update the babel-runtime npm package and their .babelrc plugins, a chore
with which Meteor can't help very much.
On top of that, Babel 7 is still in early beta. I don't want to ship
Meteor 1.6 with a critical component that could change in unexpected ways,
and I don't want to wait for Babel 7 to be finalized to ship Meteor 1.6.
Note that the Meteor command-line tool is still implemented using Babel 7,
which has historically been a great way to gain confidence in
Babel-related changes before pushing them out to all Meteor developers.
@GeoffreyBooth This should take some pressure off the CoffeeScript upgrade
for now. Let's aim for Meteor 1.6.1 for Babel 7 and CoffeeScript 2.0.
Calling unwatchFile may result in stopping the watcher before watchFile is
called, which then restarts it. This temporary stoppage appears to cause
change events to be missed sometimes. In particular, preventing this
stop/start with the acrobatics in this commit seems to fix recent
compiler-plugins.js test failures.
* When awaiting Mongo, wait until the heartbeat has pulsed after election.
> Prologue: A heartbeat is used amongst members of a MongoDB replica set
to poll the status of said members.
When we are initiating a new replicaset for the test Mongo server, the
replicaset is not fully prepared to accept writes until the voting
members have negotiated and propagated their decision about who is the
"primary" to all members involved. This seems to be delayed by almost
_exactly_ the default heartbeat interval, which is 2000ms.
The heartbeat interval is marked as an "internal only" property in Mongo
so I was hesitant to lower it. It's also a new property in Mongo 3.2
which might explain why this cropped up a while ago.
I believe this heartbeat delay is the only explanation for why the
`rs.status()` (i.e. `replSetGetStatus`) believes it is ready before the
`mongod` has actually printed "transition to primary complete" to the
log.
Fixesmeteor/meteor#9026.
* Replace addl. variable occurrence with the new `firstMemberState` var.
This is another way of addressing the problem I attempted to fix with
f34c5ec926 earlier today.
Apparently, older versions of compiler plugin-registering packages such as
standard-minifier-css and templating-compiler still depend on older
versions of the meteor package, which may still use path.join to import
fibers/future. This can be fixed by republishing those packages, as I did
in 917b01ac5f, but I'd prefer not to
republish every compiler plugin package.
Fortunately, we can also solve the problem by being more tolerant in the
implementation of Npm.require, which is what this commit does.
Ever since Meteor 1.3 first introduced a module system based on something
other than `Npm.require`, we've continued throwing missing module
exceptions that refer to `Npm.depends` and/or `Npm.require`, even if the
developer called `require` or used an `import` declaration. This commit
fixes that, so that all missing module exceptions look like 'Cannot find
module "module/name"'.
I also noticed recently that `Npm.require` is capable of returning modules
installed in `node_modules` directories completely outside the app, which
is bad news for development/production reproducibility. Fixed that too.
CC @hwillson who has spoken of deprecating `Npm.require` entirely, and
just using `require` everywhere, instead.
