New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attach from outside (standalone) ndb #60

Open
rosshadden opened this Issue Jul 26, 2018 · 9 comments

Comments

Projects
None yet
4 participants
@rosshadden

rosshadden commented Jul 26, 2018

Is there a way to leave ndb running and have scripts executed with node --inspect be picked up by it?
My current workflow is I open a standalone Node inspector from within Chrome, and leave it running. As I run my scripts that debugger attaches to them.

I can't figure out how to get a standalone ndb to attach to my script launched with node --inspect from an external terminal. Yes I know I can click specific npm scripts but my workflow is more complicated than clicking a script to run. I use commands to automatically launch build scripts when the filesystem changes, like git ls **/*.ts | entr npm run debug (which runs node --inspect).

@ak239

This comment has been minimized.

Collaborator

ak239 commented Jul 26, 2018

We may have three options here:

  1. allow user to set ports that ndb should listen and auto connects as soon as node runs,
  2. provide a special script that you can run inside your terminal and then ndb auto connects to any node process that runs from that terminal session,
  3. you can run your debug command from builtin terminal (press escape to open drawer, terminal is next tab to console) and ndb should auto connect to any node process started from terminal.

In 2 and 3 you do not need to pass --inspect as node argument, everything should happen automatically. Option 3 is already available, could your try it?

  1. Open ndb from your project folder.
  2. Go to terminal tab.
  3. Run your magic command git ls **/*.ts | entr npm run debug (you may try to remove --inspect if it does not work as is).
@rosshadden

This comment has been minimized.

rosshadden commented Jul 26, 2018

It attaches on first run, but changes do not run the app again. Basically entr (and also nodemon) fails to do its job, despite working great in my normal terminal. I used a much more simple command to test in case the globbing I used in my example above is zsh-specific.

To avoid getting into the specifics of ndb's terminal or the specific programs I'm using, what are your thoughts on your options 1 and 2? I'm sure we could get 3 working with the most minimal amount of work, but I don't like 3 very much ;).

Thanks for the quick response!

@ak239

This comment has been minimized.

Collaborator

ak239 commented Jul 26, 2018

I will experiment with nodemon to better understand why option 3 fails and I think I will add something like ndb-observer in addition to ndb binary that will force every node in current terminal to be detected by ndb, it is option 2.
Thanks for testing!

@ak239

This comment has been minimized.

Collaborator

ak239 commented Sep 14, 2018

I have a little experiment that might help with this issue: ndb-inspect.

You install this pkg as dev dependency and use -r ndb-inspect instead of --inspect and -r ndb-inspect/brk instead of --inspect-brk. ndb (starting 1.0.25) will automatically detect these processes and connect to them. It will work best if your run ndb from the folder with your app source code.

Looking forward for your feedback.

@natew

This comment has been minimized.

natew commented Sep 18, 2018

@ak239 this is really cool. Any chance this would work with electron then? Ndb is just a couple steps from replacing our custom puppeteer setup that hooks into a node + electron + electron-remote processes I think, and this is one of them (electron and having it stay stable across restarts are others).

@464bb26bac556e85b6fd6b524347b103

This comment has been minimized.

464bb26bac556e85b6fd6b524347b103 commented Oct 10, 2018

  1. allow user to set ports that ndb should listen and auto connects as soon as node runs,

Chrome has been unstable for me lately and I've been itching to switch over to something more focused. This quoted step is the biggest blocker for using ndb as a drop-in replacement in my own workflow right now.

Maybe I'm wildly off the mark here, but having this functionality out of the box could help with retention of users that otherwise would dip in to check it out, realize they can't attach to their running process, and move back to full blown chrome where it 'just works'.

@ak239

This comment has been minimized.

Collaborator

ak239 commented Oct 10, 2018

We have --inspect replacement for local debugging. Please try ndb-inspect:

  1. install it as local dev dependency,
  2. replace any --inspect with -r ndb-inspect and --inspect-brk with -r ndb-inspect/brk
  3. ideally run ndb from the folder which contains project that you would like to debug.

Would this solution work for you?

@464bb26bac556e85b6fd6b524347b103

This comment has been minimized.

464bb26bac556e85b6fd6b524347b103 commented Oct 11, 2018

That's definitely a huge improvement in terms of convenience, for sure. From a more general perspective, though, I think the fact that it necessitates changing package.json/launch.json/etc introduces that little bit of friction that may hold people back that would otherwise experiment with it more. Again I could be clueless here but thought it might be helpful to add my view.

@ak239

This comment has been minimized.

Collaborator

ak239 commented Nov 25, 2018

Some updates:

  • ndb as dependency does not contain Chromium binary any more, so it is not a huge dev dependency,
  • it is possible to use global ndb installation, you need to locate your global node_modules folder first and then add it to NODE_PATH environment variable by running something like export NODE_PATH=$NODE_PATH:/path/to/global/node_modules, after you can use -r ndb/inspect as --inspect replacement and -r ndb/inspect-brk as --inspect-brk replacement.

@ak239 ak239 added the enhancement label Dec 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment