This repository has been archived by the owner on Jun 29, 2021. It is now read-only.
Request 2 meteor debug modes #194
Comments
This was referenced Oct 9, 2017
Closed
benjamn
pushed a commit
to meteor/meteor
that referenced
this issue
Oct 9, 2017
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 meteor/meteor-feature-requests#194.
benjamn
added a commit
to meteor/meteor
that referenced
this issue
Oct 10, 2017
…#9201) 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 meteor/meteor-feature-requests#194.
|
Implemented in Meteor |
|
Works great!! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What
Support 2 meteor debug modes:
meteor debugbehavior)--inspectfor later debugger connection but do not stop the server.Why
The continue mode is more convenient for most Meteor debug scenarios. With continue mode during development you can always run with the
--inspectflag set and connect debuggers as needed.debugging a method can be handled by setting breakpoints on the methods then firing some client code that would hit the breakpoint. (don't need a startup break)
debugging a publish function can be handled by setting breakpoints on the publish and doing a client side subscribe will cause the breakpoint to be hit. (don't need a startup break)
debugging server side helper functions can also be handled by setting a breakpoint then using the client to execute functions that will cause the server functions to hit the breakpoints. (don't need a startup break)
sometimes it may be more convenient to debug startup code by placing a
debugger;statement in the startup code and then restarting the server and let the code hit the debugger statement. (a startup break can be inconvenient)Once you have solved the problem you can rerun the server with the
--inspectflag without ever attaching a debugger and the server will run fine.As a problem comes up you can attach a debugger and drop a breakpoint where you need it. (Prior to v1.6 I never ran
meteor debug, I would setNODE_OPTIONSto--debugwhile I was developing and I could connect at any time. Very convenient for the debug-edit-build-test cycle.)After debug, making a code change will kick off the automatic rebuild and the server runs fine with the
--inspectflag. No interruption from a startup break.The stop mode behavior is useful for initialization debugging but it interrupts the debug-edit-build cycle for most Meteor debug scenarios.
v1.6 Current behavior
meteor debug- fires up the server and stops within a meteor function with a debugger statement. Essentially, this is a more convenient stop than the one usually provided bynode --inspect-brk. This is stop mode.v1.6 Suggested behavior
meteor debug-brk- fire up the server and stops within the meteor function. Essentially, themeteor debugbehavior today. This becomes stop mode.meteor debug- fire up the server with the--inspectflag but do not stop the server. This becomes continue mode.The text was updated successfully, but these errors were encountered: