I have some debugger statements in my module under test and want to run mocha with --debug-brk set and hit my breakpoint so that I can inspect the state of my module. Unfortunately, whenever I run mocha with this option, I end up with a blank cursor on the next line. I can enter text, but there's nothing that appears to be processing my commands (it certainly doesn't look like the node debugger):
$ mocha --debug-brk tests.js -R spec
debugger listening on port 5858
[BLANK CURSOR]
Am I doing something wrong with how I'm launching mocha?
UPDATE
As of mocha 7.0.0, --debug-brk has been removed in favor of --inspect-brk
Using a recent version of nodejs (>=v6.3.0) and mocha (>=3.1.0), you can use V8 inspector integration.
V8 Inspector integration allows attaching Chrome DevTools to Node.js
instances for debugging and profiling
Usage
--inspect activates V8 inspector integration, and --debug-brk adds a breakpoint at the beginning. Since nodejs v7.6.0 and mocha v3.3.0, you can use the --inspect-brk shorthand for --inspect --debug-brk
$ mocha --debug-brk --inspect
Debugger listening on port 9229.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/remote/serve_file/#62cd277117e6f8ec53e31b1be58290a6f7ab42ef/inspector.html?experiments=true&v8only=true&ws=localhost:9229/node
With npm scripts
If you have a npm test script that uses mocha, you can pass the options from npm to your mocha script by using the end of option delimiter --:
$ npm test -- --inspect --debug-brk
Chrome tip
Instead of copy-pasting the url each time, go to chrome://inspect and click the appropriate link in the "Remote target" section.
To answer the original question, even though I also suggest you look into node-inspector: you can use the CLI debugger built into node through mocha with the debug option, instead of the --debug or --debug-brk flags. (Notice the lack of dashes.)
In your example, instead, it would be:
$ mocha debug tests.js -R spec
debugger listening on port 5858
connecting... ok
break in node_modules/mocha/bin/_mocha:7
5 */
6
7 var program = require('commander')
8 , sprintf = require('util').format
9 , path = require('path')
debug> [CURSOR]
Again, debug as above in bold, with no dashes. (=
Relevant: https://github.com/visionmedia/mocha/issues/247
I was able to get this to work using node-inspector. I run my test like you show in one shell:
mocha --debug-brk mocha/test.js
and then run node-inspector in a second shell:
node-inspector
Bringing up the URL that node-inspector spits out in a browser allows me to debug with the web inspector.
http://127.0.0.1:8080/debug?port=5858
If you have node-insector installed you can debug you Mocha tests without actually running node-inspector first. The easiest way is to
node-debug _mocha
That should start debugging the node tests in chrome (also works on Safari)
One reason I have seen that the tests do not work is sometimes you gave to try http://localhost:8080/debug?port=5858 or http://127.0.0.1:8080/debug?port=5858
run mocha with flag --inspect-brk and click 'open dedicated DevTools for node' in chrome from page chrome://inspect. In dedicated DevTools window add connection localhost:9229 to connect automatically.
Also add a debugger statement to the file you want debug.
(this is using latest versions of node and chrome as of October 2017)
I'd like for my chrome extension to reload every time I save a file in the extension folder, without having to explicitly click "reload" in chrome://extensions/. Is this possible?
Edit: I'm aware I can update the interval at which Chrome reloads extensions, which is a half-way solution, but I'd rather either making my editor (emacs or textmate) trigger on-save a reload or asking Chrome to monitor the directory for changes.
You can use "Extensions Reloader" for Chrome:
Reloads all unpacked extensions using the extension's toolbar button or by browsing to "http://reload.extensions"
If you've ever developed a Chrome extension, you might have wanted to
automate the process of reloading your unpacked extension without the
need of going through the extensions page.
"Extensions Reloader" allows you to reload all unpacked extensions
using 2 ways:
1 - The extension's toolbar button.
2 - Browsing to "http://reload.extensions".
The toolbar icon will reload unpacked extensions using a single click.
The "reload by browsing" is intended for automating the reload process
using "post build" scripts - just add a browse to
"http://reload.extensions" using Chrome to your script, and you'll
have a refreshed Chrome window.
Update: As of January 14, 2015, the extension is open-sourced and available on GitHub.
Update: I have added an options page, so that you don't have to manually find and edit the extension's ID any more. CRX and source code are at: https://github.com/Rob--W/Chrome-Extension-Reloader
Update 2: Added shortcut (see my repository on Github).
The original code, which includes the basic functionality is shown below.
Create an extension, and use the Browser Action method in conjunction with the chrome.extension.management API to reload your unpacked extension.
The code below adds a button to Chrome, which will reload an extension upon click.
manifest.json
{
"name": "Chrome Extension Reloader",
"version": "1.0",
"manifest_version": 2,
"background": {"scripts": ["bg.js"] },
"browser_action": {
"default_icon": "icon48.png",
"default_title": "Reload extension"
},
"permissions": ["management"]
}
bg.js
var id = "<extension_id here>";
function reloadExtension(id) {
chrome.management.setEnabled(id, false, function() {
chrome.management.setEnabled(id, true);
});
}
chrome.browserAction.onClicked.addListener(function(tab) {
reloadExtension(id);
});
icon48.png: Pick any nice 48x48 icon, for example:
I've made a simple embeddable script doing hot reload:
https://github.com/xpl/crx-hotreload
It watches for file changes in an extension's directory. When a change detected, it reloads the extension and refreshes the active tab (to re-trigger updated content scripts).
Works by checking timestamps of files
Supports nested directories
Automatically disables itself in the production configuration
in any function or event
chrome.runtime.reload();
will reload your extension (docs). You also need to change the manifest.json file, adding:
...
"permissions": [ "management" , ...]
...
I am using a shortcut to reload. I don't want to reload all the time when I save a file
So my approach is lightweight, and you can leave the reload function in
manifest.json
{
...
"background": {
"scripts": [
"src/bg/background.js"
],
"persistent": true
},
"commands": {
"Ctrl+M": {
"suggested_key": {
"default": "Ctrl+M",
"mac": "Command+M"
},
"description": "Ctrl+M."
}
},
...
}
src/bg/background.js
chrome.commands.onCommand.addListener((shortcut) => {
console.log('lets reload');
console.log(shortcut);
if(shortcut.includes("+M")) {
chrome.runtime.reload();
}
})
Now press Ctrl + M in the chrome browser to reload
Another solution would be to create custom livereload script (extension-reload.js):
// Reload client for Chrome Apps & Extensions.
// The reload client has a compatibility with livereload.
// WARNING: only supports reload command.
var LIVERELOAD_HOST = 'localhost:';
var LIVERELOAD_PORT = 35729;
var connection = new WebSocket('ws://' + LIVERELOAD_HOST + LIVERELOAD_PORT + '/livereload');
connection.onerror = function (error) {
console.log('reload connection got error:', error);
};
connection.onmessage = function (e) {
if (e.data) {
var data = JSON.parse(e.data);
if (data && data.command === 'reload') {
chrome.runtime.reload();
}
}
};
This script connects to the livereload server using websockets. Then, it will issue a chrome.runtime.reload() call upon reload message from livereload. The next step would be to add this script to run as background script in your manifest.json, and voila!
Note: this is not my solution. I'm just posting it. I found it in the generated code of Chrome Extension generator (Great tool!). I'm posting this here because it might help.
TL;DR
Create a WebSocket server that dispatches a message to a background script that can handle the update. If you are using webpack and don't plan to do it yourself, webpack-run-chrome-extension can help.
Answer
You can create a WebSocket server to communicate with the extension as a WebSocket client (via window object). The extension would then listen for file changes by attaching the WebSocket server to some listener mechanism (like webpack devServer).
Did the file change? Set the server to dispatch a message to the extension asking for updates (broadcasting the ws message to the client(s)). The extension then reloads, replies with "ok, reloaded" and keeps listening for new changes.
Plan
Set up a WebSocket server (to dispatch update requests)
Find a service that can tell you when did the files change (webpack/other bundler software)
When an update happens, dispatch a message to client requesting updates
Set up a WebSocket client (to receive update requests)
Reload the extension
How
For the WebSocket server, use ws. For file changes, use some listener/hook (like webpack's watchRun hook). For the client part, native WebSocket. The extension could then attach the WebSocket client on a background script for keeping sync persistent between the server (hosted by webpack) and the client (the script attached in the extension background).
Now, to make the extension reload itself, you can either call chrome.runtime.reload() in it each time the upload request message comes from the server, or even create a "reloader extension" that would do that for you, using chrome.management.setEnabled() (requires "permissions": [ "management" ] in manifest).
In the ideal scenario, tools like webpack-dev-server or any other web server software could offer support for chrome-extension URLs natively. Until that happens, having a server to proxy file changes to your extension seems to be the best option so far.
Available open-source alternative
If you are using webpack and don't want to create it all yourself, I made webpack-run-chrome-extension, which does what I planned above.
Chrome Extensions have a permission system that it wouldn't allow it (some people in SO had the same problem as you), so requesting them to "add this feature" is not going to work IMO. There's a mail from Chromium Extensions Google Groups with a proposed solution (theory) using chrome.extension.getViews(), but is not guaranteed to work either.
If it was possible to add to the manifest.json some Chrome internal pages like chrome://extensions/, it would be possible to create a plugin that would interact to the Reload anchor, and, using an external program like XRefresh (a Firefox Plugin - there's a Chrome version using Ruby and WebSocket), you would achieve just what you need:
XRefresh is a browser plugin which
will refresh current web page due to
file change in selected folders. This
makes it possible to do live page
editing with your favorite HTML/CSS
editor.
It's not possible to do it, but I think you can use this same concept in a different way.
You could try to find third-party solutions instead that, after seeing modifications in a file (I don't know emacs neither Textmate, but in Emacs it would be possible to bind an app call within a "save file" action), just clicks in an specific coordinate of an specific application: in this case it's the Reload anchor from your extension in development (you leave a Chrome windows opened just for this reload).
(Crazy as hell but it may work)
Here's a function that you can use to watch files for changes, and reload if changes are detected. It works by polling them via AJAX, and reloading via window.location.reload(). I suppose you shouldn't use this in a distribution package.
function reloadOnChange(url, checkIntervalMS) {
if (!window.__watchedFiles) {
window.__watchedFiles = {};
}
(function() {
var self = arguments.callee;
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState == 4) {
if (__watchedFiles[url] &&
__watchedFiles[url] != xhr.responseText) {
window.location.reload();
} else {
__watchedFiles[url] = xhr.responseText
window.setTimeout(self, checkIntervalMS || 1000);
}
}
};
xhr.open("GET", url, true);
xhr.send();
})();
}
reloadOnChange(chrome.extension.getURL('/myscript.js'));
The great guys at mozilla just released a new https://github.com/mozilla/web-ext that you can use to launch web-ext run --target chromium
Maybe I'm a little late to the party, but I've solved it for me by creating https://chrome.google.com/webstore/detail/chrome-unpacked-extension/fddfkmklefkhanofhlohnkemejcbamln
It works by reloading chrome://extensions page, whenever file.change events are incoming via websockets.
A Gulp-based example of how to emit file.change event upon file changes in an extension folder can be found here: https://github.com/robin-drexler/chrome-extension-auto-reload-watcher
Why reloading the entire tab instead of just using the extensions management api to reload/re-enable extensions? Currently disabling and enabling extensions again causes any open inspection window (console log etc.) to close, which I found to be too annoying during active development.
There's an automatic reload plugin if you're developing using webpack:
https://github.com/rubenspgcavalcante/webpack-chrome-extension-reloader
const ChromeExtensionReloader = require('webpack-chrome-extension-reloader');
plugins: [
new ChromeExtensionReloader()
]
Also comes with a CLI tool if you don't want to modify webpack.config.js:
npx wcer
Note: an (empty) background script is required even if you don't need it because that's where it injects reload code.
Maybe a bit late answer but I think crxreload might work for you. It's my result of trying to have a reload-on-save workflow while developing.
Use npm init to create a package.json in directory root, then
npm install --save-dev gulp-open && npm install -g gulp
then create a gulpfile.js
which looks like:
/* File: gulpfile.js */
// grab our gulp packages
var gulp = require('gulp'),
open = require('gulp-open');
// create a default task and just log a message
gulp.task('default', ['watch']);
// configure which files to watch and what tasks to use on file changes
gulp.task('watch', function() {
gulp.watch('extensionData/userCode/**/*.js', ['uri']);
});
gulp.task('uri', function(){
gulp.src(__filename)
.pipe(open({uri: "http://reload.extensions"}));
});
This works for me developing with CrossRider, you might watch to change the path you watch the files at, also assuming you have npm and node installed.
Your content files such has html and manifest files are not changeable without installation of the extension, but I do believe that the JavaScript files are dynamically loaded until the extension has been packed.
I know this because of a current project im working on via the Chrome Extensions API, and seems to load every-time i refresh a page.
Disclaimer: I developed this extension myself.
Clerc - for Chrome Live Extension Reloading Client
Connect to a LiveReload compatible server to automatically reload your extension every time you save.
Bonus: with a little extra work on your part, you can also automatically reload the webpages that your extension alters.
Most webpage developers use a build system with some sort of watcher that automatically builds their files and restarts their server and reloads the website.
Developing extensions shouldn't need to be that different. Clerc brings this same automation to Chrome devs. Set up a build system with a LiveReload server, and Clerc will listen for reload events to refresh your extension.
The only big gotcha is changes to the manifest.json. Any tiny typos in the manifest will probably cause further reload attempts to fail, and you will be stuck uninstalling/reinstalling your extension to get your changes loading again.
Clerc forwards the complete reload message to your extension after it reloads, so you can optionally use the provided message to trigger further refresh steps.
Thanks to #GmonC and #Arik and some spare time, I managet to get this working. I have had to change two files to make this work.
(1) Install LiveReload and Chrome Extension for that application.
This will call some script on file change.
(2) Open <LiveReloadInstallDir>\Bundled\backend\res\livereload.js
(3) change line #509 to
this.window.location.href = "http://reload.extensions";
(4) Now install another extension Extensions Reloader which has useful link handler that reload all development extensions on navigating to "http://reload.extensions"
(5) Now change that extension's background.min.js in this way
if((d.installType=="development")&&(d.enabled==true)&&(d.name!="Extensions Reloader"))
replace with
if((d.installType=="development")&&(d.enabled==true)&&(d.name!="Extensions Reloader")&&(d.name!="LiveReload"))
Open LiveReload application, hide Extension Reloader button and activate LiveReload extension by clicking on button in toolbar, you will now reload page and extensions on each file change while using all other goodies from LiveReload (css reload, image reload etc.)
Only bad thing about this is that you will have to repeat procedure of changing scripts on every extension update. To avoid updates, add extension as unpacked.
When I'll have more time to mess around with this, I probably will create extension that eliminates need for both of these extensions.
Untill then, I'm working on my extension Projext Axeman
Just found a newish grunt based project that provides bootstrapping, scaffolding, some automated pre-processing faculty, as well as auto-reloading (no interaction needed).
Bootstrap Your Chrome Extension from Websecurify
I want to reload (update) my extensions overnight, this is what I use in background.js:
var d = new Date();
var n = d.getHours();
var untilnight = (n == 0) ? 24*3600000 : (24-n)*3600000;
// refresh after 24 hours if hour = 0 else
// refresh after 24-n hours (that will always be somewhere between 0 and 1 AM)
setTimeout(function() {
location.reload();
}, untilnight);
Regards,
Peter
I primarily develop in Firefox, where web-ext run automatically reloads the extension after files change. Then once it's ready, I do a final round of testing in Chrome to make sure there aren't any issues that didn't show up in Firefox.
If you want to develop primarily in Chrome, though, and don't want to install any 3rd party extensions, then another option is to create a test.html file in the extension's folder, and add a bunch of SSCCE's to it. That file then uses a normal <script> tag to inject the extension script.
You could use that for 95% of testing, and then manually reload the extension when you want to test it on live sites.
That doesn't identically reproduce the environment that an extension runs in, but it's good enough for many simple things.
MAC ONLY
Using Extensions Reloader:
Using Typescript
Add the watcher of your to your project: yarn add tsc-watch
Add command to scripts to package.json
...
"scripts": {
"dev": "tsc-watch --onSuccess \"open -a '/Applications/Google Chrome.app' 'http://reload.extensions'\""
},
...
Run script yarn dev
Using JavaScript
Add the watcher of your to your project: yarn add watch-cli
Add command to scripts to package.json
...
"scripts": {
"dev": "watch -p \"**/*.js\" -c \"open -a '/Applications/Google Chrome.app' 'http://reload.extensions'\""
},
...
Run script yarn dev
Bonus: Turn on 'reload current tab' in Extensions Reloader options, so it reloads after a change was made:
I've forked LiveJS to allow for live reloading of Packaged Apps. Just include the file in your app and every time you save a file the app will autoreload.
As mentioned in the docs: the following command line will reload an app
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --load-and-launch-app=[path to the app ]
so I just created a shell script and called that file from gulp. Super simple:
var exec = require('child_process').exec;
gulp.task('reload-chrome-build',function(cb){
console.log("reload");
var cmd="./reloadchrome.sh"
exec(cmd,function (err, stdout, stderr) {
console.log("done: "+stdout);
cb(err);
}
);});
run your necessary watch commands on scripts and call the reload task when you want to. Clean, simple.
This is where software such as AutoIt or alternatives shine. The key is writing a script which emulates your current testing phase. Get used to using at least one of them as many technologies do not come with clear workflow/testing paths.
Run("c:\Program Files (x86)\Google\Chrome\Application\chrome.exe")
WinWaitActive("New Tab - Google Chrome")
Send("^l")
Send("chrome://extensions{ENTER}")
WinWaitActive("Extensions - Google Chrome")
Send("{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}")
Send("{ENTER}")
WinWaitActive("Extensions - Google Chrome")
Send("{TAB}{TAB}")
Send("{ENTER}")
WinWaitActive("Developer Tools")
Send("^`")
Obviously you change the code to suit your testing/iterating needs. Make sure tab clicks are true to where the anchor tag is in the chrome://extensions site. You could also use relative to window mouse movements and other such macros.
I would add the script to Vim in a way similar to this:
map <leader>A :w<CR>:!{input autoit loader exe here} "{input script location here}"<CR>
This means that when I'm in Vim I press the button above ENTER (usually responsible for: | and \) known as the leader button and follow it with a capital 'A' and it saves and begins my testing phase script.
Please make sure to fill in the {input...} sections in the above Vim/hotkey script appropriately.
Many editors will allow you to do something similar with hotkeys.
Alternatives to AutoIt can be found here.
For Windows: AutoHotkey
For Linux: xdotool, xbindkeys
For Mac: Automator
If you have a Mac, ¡the easiest way is with Alfred App!
Just get Alfred App with Powerpack, then add the workflow provided in the link below and customise the hotkey you want (I like to use ⌘ + ⌥ + R). That's all.
Now, every time you use the hotkey, Google Chrome will reload, no matter which application you're at that moment.
If you want to use other browser, open the AppleScript inside Alfred Preferences Workflows and replace "Google Chrome" with "Firefox", "Safari", ...
I also will show here the content of the /usr/bin/osascript script used in the ReloadChrome.alfredworkflow file so you can see what it is doing.
tell application "Google Chrome"
activate
delay 0.5
tell application "System Events" to keystroke "r" using command down
delay 0.5
tell application "System Events" to keystroke tab using command down
end tell
The workflow file is ReloadChrome.alfredworkflow.
The author recommended the next version of that webpack plugin: https://github.com/rubenspgcavalcante/webpack-extension-reloader. It works very well for me.
Yes,you can do it indirectly! Here is my solution.
In manifest.json
{
"name": "",
"version": "1.0.0",
"description": "",
"content_scripts":[{
"run_at":"document_end",
"matches":["http://*/*"],
"js":["/scripts/inject.js"]
}]
}
In inject.js
(function() {
var script = document.createElement('script');
script.type = 'text/javascript';
script.async = true;
script.src = 'Your_Scripts';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(script, s);
})();
Your injected script can inject other script from any location.
Another benefit from this technic is that you can just ignore the limitation of isolated world. see content script execution environment
BROWSER-SYNC
Using the amazing Browser-Sync
update browsers (any) when source code changes (HTML, CSS, images, etc.)
support Windows, MacOS and Linux
you could even watch your code updates (live) using your mobile devices
Instalation on MacOS (view their help to install on other OS)
Install NVM, so you can try any Node version
brew install nvm # install a Node version manager
nvm ls-remote # list available Node versions
nvm install v10.13.0 # install one of them
npm install -g browser-sync # install Browser-Sync
How to use browser-sync for static sites
Let's see two examples:
browser-sync start --server --files . --host YOUR_IP_HERE --port 9000
browser-sync start --server --files $(ack --type-add=web:ext:htm,html,xhtml,js,css --web -f | tr \\n \ ) --host $(ipconfig getifaddr en0) --port 9000
The --server option allow you to run a local server anywhere you are in your terminal and --files let you specify which files will be tracked for changes. I prefer to be more specific for the tracked files, so in the second example I use ack for listing specific file extensions (is important that those files do not have filenames with spaces) and also useipconfig to find my current IP on MacOS.
How to use browser-sync for dynamic sites
In case you are using PHP, Rails, etc., you already have a running server, but it doesn't refresh automatically when you make changes to your code. So you need to use the --proxy switch to let browser-sync know where is the host for that server.
browser-sync start --files $(ack --type-add=rails:ext:rb,erb,js,css,sass,scss,coffee --rails -f | tr \\n \ ) --proxy 192.168.33.12:3000 --host $(ipconfig getifaddr en0) --port 9000 --no-notify --no-open
In the above example, I already have a Rails app running on my browser on 192.168.33.12:3000. It really runs on a VM using a Vagrant box, but I could access the virtual machine using port 3000 on that host. I like --no-notify to stop browser-sync sending me a notification alert on the browser every time I change my code and --no-open to stop browser-sync behavior that immediately loads a browser tab when the server start.
IMPORTANT: Just in case you're using Rails, avoid using Turbolinks on development, otherwise you will not be able click on your links while using the --proxy option.
Hope it would be useful to someone. I've tried many tricks to refresh the browser (even an old post I've submitted on this StackOverflow question using AlfredApp time ago), but this is really the way to go; no more hacks, it just flows.
CREDIT: Start a local live reload web server with one command
It can't be done directly. Sorry.
If you would like to see it as a feature you can request it at http://crbug.com/new