npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

ti-debugger

v0.1.0

Published

Titanium Debugger (based on node-inspector)

Downloads

2

Readme

Titanium Debugger

Overview

Titanium Debugger is a debugger interface for Appcelerator Titanium applications that uses the Blink Developer Tools (formerly WebKit Web Inspector).

The project maintenance and support is sponsored by StrongLoop.

Table of Content

Quick Start

Install

$ npm install -g ti-debugger

Start

$ node-debug app.js

where app.js is the name of your main Node application JavaScript file.

See available configuration options here

Debug

The node-debug command will load Titanium Debugger in your default browser.

NOTE: Titanium Debugger works in Chrome and Opera only. You have to re-open the inspector page in one of those browsers if another browser is your default web browser (e.g. Safari or Internet Explorer).

Titanium Debugger works almost exactly as the Chrome Developer Tools. Read the excellent DevTools overview to get started.

Other useful resources:

Features

The Blink DevTools debugger is a powerful JavaScript debugger interface. Titanium Debugger supports almost all of the debugging features of DevTools, including:

  • Navigate in your source files
  • Set breakpoints (and specify trigger conditions)
  • Step over, step in, step out, resume (continue)
  • Inspect scopes, variables, object properties
  • Hover your mouse over an expression in your source to display its value in a tooltip
  • Edit variables and object properties
  • Continue to location
  • Break on exceptions
  • Disable/enable all breakpoints
  • CPU and HEAP profiling
  • Network client requests inspection
  • Console output inspection

Cool stuff

  • Titanium Debugger uses WebSockets, so no polling for breaks.
  • Remote debugging
  • Live edit of running code, optionally persisting changes back to the file-system.
  • Set breakpoints in files that are not loaded into V8 yet - useful for debugging module loading/initialization.
  • Embeddable in other applications - see Embedding HOWTO for more details.

Known Issues

  • Be careful about viewing the contents of Buffer objects, each byte is displayed as an individual array element; for most Buffers this will take too long to render.
  • While not stopped at a breakpoint the console doesn't always behave as you might expect. See the issue #146.
  • Break on uncaught exceptions does not work in all Node versions, you need at least v0.11.3 (see node#5713).

Troubleshooting

My script runs too fast to attach the debugger.

The debugged process must be started with --debug-brk, this way the script is paused on the first line.

Note: node-debug adds this option for you by default.

I got the UI in a weird state.

When in doubt, refresh the page in browser

Can I debug remotely?

Yes. Titanium Debugger must be running on the same machine, but your browser can be anywhere. Just make sure port 8080 is accessible.

How do I specify files to hide?

Create a JSON-encoded array. You must escape quote characters when using a command-line option.

$ ti-debugger --hidden='["node_modules/framework"]'

Note that the array items are interpreted as regular expressions.

UI doesn't load or doesn't work and refresh didn't help

Make sure that you have adblock disabled as well as any other content blocking scripts and plugins.

How can I (selectively) delete debug session metadata?

You may want to delete debug session metadata if for example Titanium Debugger gets in a bad state with some watch variables that were function calls (possibly into some special c-bindings). In such cases, even restarting the application/debug session may not fix the problem.

Titanium Debugger stores debug session metadata in the HTML5 local storage. You can inspect the contents of local storage and remove any items as needed. In Google Chrome, you can execute any of the following in the JavaScript console:

// Remove all
window.localStorage.clear()
// Or, to list keys so you can selectively remove them with removeItem()
window.localStorage
// Remove all the watch expressions
window.localStorage.removeItem('watchExpressions')
// Remove all the breakpoints
window.localStorage.removeItem('breakpoints')

When you are done cleaning up, hit refresh in the browser.

Titanium Debugger takes a long time to start up.

Try setting --no-preload to true. This option disables searching disk for *.js at startup. Code will still be loaded into Titanium Debugger at runtime, as modules are required.

How do I debug Mocha unit-tests?

You have to start _mocha as the debugged process and make sure the execution pauses on the first line. This way you have enough time to set your breakpoints before the tests are run.

$ node-debug _mocha

How do I debug Gulp tasks?

If you are running on a Unix system you can simply run the following command. The $(which ..) statement gets replaced with the full path to the gulp-cli.

$ node-debug $(which gulp) task

If you are running on Windows, you have to get the full path of gulp.js to make an equivalent command:

> node-debug %appdata%\npm\node_modules\gulp\bin\gulp.js task

You can omit the task part to run the default task.

Advanced Use

While running node-debug is a convenient way to start your debugging session, there may come time when you need to tweak the default setup.

There are three steps needed to get you up and debugging:

1. Start the Titanium Debugger server

$ ti-debugger

You can leave the server running in background, it's possible to debug multiple processes using the same server instance.

2. Enable debug mode in your Node process

You can either start Node with a debug flag like:

$ node --debug your/node/program.js

or, to pause your script on the first line:

$ node --debug-brk your/short/node/script.js

Or you can enable debugging on a node that is already running by sending it a signal:

  1. Get the PID of the node process using your favorite method. pgrep or ps -ef are good

    $ pgrep -l node
    2345 node your/node/server.js
  2. Send it the USR1 signal

    $ kill -s USR1 2345
Windows

Windows does not support UNIX signals. To enable debugging, you can use an undocumented API function process._debugProcess(pid):

  1. Get the PID of the node process using your favorite method, e.g.

    > tasklist /FI "IMAGENAME eq node.exe"
    
    Image Name                     PID Session Name        Session#    Mem Usage
    ========================= ======== ================ =========== ============
    node.exe                      3084 Console                    1     11,964 K
  2. Call the API:

    > node -e "process._debugProcess(3084)"

3. Load the debugger UI

Open http://127.0.0.1:8080/?port=5858 in the Chrome browser.

Configuration

Both ti-debugger and node-debug use rc module to manage configuration options.

Places for configuration:

  • command line arguments (parsed by yargs)
  • environment variables prefixed with ti-debugger_
  • if you passed an option --config file then from that file
  • a local .ti-debuggerrc or the first found looking in ./ ../ ../../ ../../../ etc.
  • $HOME/.ti-debuggerrc
  • $HOME/.ti-debugger/config
  • $HOME/.config/ti-debugger
  • $HOME/.config/ti-debugger/config
  • /etc/ti-debuggerrc
  • /etc/ti-debugger/config

All configuration sources that where found will be flattened into one object, so that sources earlier in this list override later ones.

Options

| Option | Alias | Default | Description | | :------------------ | :-: | :-----: | :-------- | | general | --help | -h | | Display information about available options.Use --help -l to display full usage info.Use --help <option> to display quick help on option. | --version | -v | | Display Titanium Debugger's version. | --debug-port | -d | 5858 | Node/V8 debugger port.(node --debug={port}) | --web-host | | 0.0.0.0 | Host to listen on for Titanium Debugger's web interface.node-debug listens on 127.0.0.1 by default. | --web-port | -p | 8080 | Port to listen on for Titanium Debugger's web interface. | node-debug | --debug-brk | -b | true | Break on the first line.(node --debug-brk) | --nodejs | | [] | Pass NodeJS options to debugged process.(node --option={value}) | --script | | [] | Pass options to debugged process.(node app --option={value}) | --cli | -c | false | CLI mode, do not open browser. | ti-debugger | --save-live-edit | | false | Save live edit changes to disk (update the edited files). | --preload | | true | Preload *.js files. You can disable this optionto speed up the startup. | --inject | | true | Enable injection of debugger extensions into the debugged process. It's possible disable only part of injections using subkeys --no-inject.network. Allowed keys : network, profiles, console. | --hidden | | [] | Array of files to hide from the UI,breakpoints in these files will be ignored.All paths are interpreted as regular expressions. | --stack-trace-limit | | 50 | Number of stack frames to show on a breakpoint. | --ssl-key | | | Path to file containing a valid SSL key. | --ssl-cert | | | Path to file containing a valid SSL certificate.

Usage examples

Command line

Format
$ node-debug [general-options] [node-debug-options] [ti-debugger-options] [script]
$ ti-debugger [general-options] [ti-debugger-options]
Usage

Display full usage info:

$ node-debug --help -l

Set debug port of debugging process to 5859:

$ node-debug -p 5859 app

Pass --web-host=127.0.0.2 to ti-debugger. Start ti-debugger to listen on 127.0.0.2:

$ node-debug --web-host 127.0.0.2 app

Pass --option=value to debugging process:

$ node-debug app --option value

Start ti-debugger to listen on HTTPS:

$ node-debug --ssl-key ./ssl/key.pem --ssl-cert ./ssl/cert.pem app

Ignore breakpoints in files stored in node_modules folder or ending in .test.js:

$ node-debug --hidden node_modules/ --hidden \.test\.js$ app

Add --harmony flag to the node process running the debugged script:

$ node-debug --nodejs --harmony app

Disable preloading of .js files:

$ node-debug --no-preload app

RC Configuration

Use dashed option names in RC files. Sample config file:

{
  "web-port": 8088,
  "web-host": null,
  "debug-port": 5858,
  "save-live-edit": true,
  "preload": false,
  "hidden": ["\.test\.js$", "node_modules/"],
  "nodejs": ["--harmony"],
  "stack-trace-limit": 50,
  "ssl-key": "./ssl/key.pem",
  "ssl-cert": "./ssl/cert.pem"
}

Contributing Code

Making Titanium Debugger the best debugger for node.js cannot be achieved without the help of the community. The following resources should help you to get started.

Credits

Maintainers

Big thanks to the many contributors to the project, see AUTHORS.