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.
This is performance-sensitive code, and I think this extra (uncached) call
to files.statOrNull could be contributing to test timeouts on Circle CI.
Follow-up to #9030.
As outlined in #3854, if `meteor --settings` points to a
directory instead of a file, an application gets caught up
in an infinite rebuild loop. Since it was assumed only a
file would be configured via `--settings`, a file watcher
is created for the specified directory, and that watcher
is then triggered ad infinitum.
These changes prevent a file watcher from being created
on a `--settings` directory.
