87ebeec54b
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.
Isobuild Static Assets
Files here are designed to be copied to the output destination of a Meteor CLI command.
Sometimes, for code sharing, the JS files can be imported by parts of the tool
(like mini-files.js - it is shared between built apps and tool).
skel - App Skeleton
skel is a folder that is the skeleton of a new fresh app. It is copied to the
destination on meteor create command. The important part of the skeleton is
the packages it includes by default.
skel-bare - Empty App Skeleton
Similar to skel, skel-bare is copied on meteor create --bare command.
skel-full - Scaffold App Skeleton
Similar to skel, skel-full is copied on meteor create --full command.
skel-pack - Package Skeleton
Similar to skel, skel-pack is copied on meteor create --package command.
server - Bundled App's Bootstrap
The server folder is copied by Isobuild when the app is bundled (on
meteor run or meteor build). The boot.js file is the default entry point
of any built Meteor app, it loads the server program and runs the files from the
manifest. It also sets up the source-maps and a backdoor for meteor shell.