When I run the firebase emulators:start command on Windows 10, it opens up a console with what looks like a java program outputting log events from the emulator suite. Is there any way to prevent this window from opening?
Thanks!
edit: This window doesn't even close after emulators:exec finishes its command, preventing a proper cleanup.
First of all , this link can help you on how to shutdown correctly the JVMs:
Shut down JVM when Firebase emulator closes
Since you're talking about Java console , then you should use javaw.exe instead of java.exe ! Javaw prevents logs from appearing in console . I'm not an expert of firebase but I believe there's a config file in which there's a call to Java binary which launches the JVM and finally change the java by javaw
Environment info
firebase --version --> 11.1.0
node -v --> v16.15.1
npm -v --> 8.11.0
Platform:
Pop!_OS 22.04 LTS 64-bit
Steps to reproduce
1). run firebase init functions
2). Select Use an existing project and choose my project.
3). Select Javascript for the language.
4). Type N and press enter to not use eslint.
5). Type Y and press enter to install dependencies.
6). run firebase emulators:start or firebase emulators:start --only functions
7). Open functions/index.js and uncomment the helloWorld example, and save.
Expected behavior
I expect the functions emulator to detect the changes to the javascript code and to automatically apply those changes without restarting the emulator (manually).
Actual behavior
Nothing changes. I have to restart the emulator to use the helloWorld function. Or if the function was there when the emulator was started I have to restart it to see changes made to the function itself. If I make changes to the firestore.rules file while running the firestore emulator those changes are registered without restarting the emulator(s) like it's supposed to.
If you're using "native" Node.js, any changes/modification in the code after running the emulator will not be reflected. By using different Javascript library, you can transpile/compile your code as watch mode before running Firebase emulator to see the changes upon modification of the code. You can also refer to this documentation:
Code changes you make during an active session are automatically
reloaded by the emulator. If your code needs to be transpiled
(TypeScript, React) make sure to do so before running the emulator.
You can run your transpiler in watch mode with commands like tsc -w to
transpile and reload code automatically as you save.
I often run a dispatcher server in sbt ~run.
unfiltered.netty.Http(port)
.handler(plan)
.run()
Http.shutdown()
When I start up my server, it says:
Embedded server running on port 8080. Press any key to stop.
However, only ENTER will stop the server. Unfortunately, ENTER also stops sbt. How can I set up unfiltered so that it actually stops on any key within sbt? I would like pressing a key to stop the server and cause sbt to re-compile and re-run the application.
You can do continuous hot reloading using sbt-revolver and JRebel. There's a free license of JRebel for Scala users.
Start sbt shell.
reStart starts a forked JVM that's exit trapped.
If you installed JRebel correctly, compiled classes from ~products would get loaded into the forked JVM.
See Hot Reloading.
I am running the BrowserStackTunnel.jar by the grunt plugin grunt-exec
(Have been using node's child_process.exec, but same results)
with the command java -jar BrowserStackTunnel.jar -force APIKEY localhost,8000,false
What the Java file actualy does is connecting via ssh to an Amazon instance of Browserstack and opening a port on 45691, the website of browserstack is polling that port on localhost where the Java application serves a small snippet containing the params passed.
If i run the command from the CLI it works fine and i see the port beeing open on netstat. In the browserstack website i get the success screen.
But if i run the command from grunt-exec it shows only the SYN request.
The output to the command line is the same, both show success
I am not so sure what is causing this. I am running on windows7, node v0.10.12, grunt-cli v0.1.9, grunt v0.4.1 and grunt exec v0.4.2
Any idea what is causing this or how to debug it? I thought about a permission problem, but i am kind of clueless
I had the same problem and I realized, better if I use the BrowserStackLocal binary files for creating a tunel. I solved a quite complex configuration here: Ember.js - CircleCI - BrowserStack
BrowserStackLocal files are here: http://www.browserstack.com/local-testing (Binaries)
Have you tried using the Browserstack Chrome Plugin? It was launched this january and allows you to test local files without running the cli tunnel.
As soon as the child process is created, grunt moves on to the next command. If there is nothing, the grunt process terminates and takes the child with it.
Try adding a grunt-contrib-watch task after the grunt-exec call. It should keep the grunt process alive, and the child process with it.
Does anyone know a good method to debug server side code?
I tried enable Node.js debug then use node-inspector but it does not show any of my code.
I end up using console.log but this is very inefficient.
Update: I found the following procedure works on my Linux machine:
When you run Meteor, it will spawn two processes
process1: /usr/lib/meteor/bin/node /usr/lib/meteor/app/meteor/meteor.js
process2: /usr/lib/meteor/bin/node /home/paul/codes/bbtest_code/bbtest02/.meteor/local/build/main.js --keepalive
You need to send kill -s USR1 on process2
Run node-inspector and you can see your server code
On my first try, I modify the last line on meteor startup script in /usr/lib/meteor/bin/meteor to
exec "$DEV_BUNDLE/bin/node" $NODE_DEBUG "$METEOR" "$#"
and run NODE_DEBUG=--debug meteor on command prompt. This only put --debug flag on process1 so I only see meteor files on node-inspector and could not find my code.
Can someone check this on Windows and Mac machine?
In Meteor 0.5.4 this has become a lot easier:
First run the following commands from the terminal:
npm install -g node-inspector
node-inspector &
export NODE_OPTIONS='--debug-brk'
meteor
And then open http://localhost:8080 in your browser to view the node-inspector console.
Update
Since Meteor 1.0 you can just type
meteor debug
which is essentially a shortcut for the above commands, and then launch node inspector in your browser as mentioned.
Update
In Meteor 1.0.2 a console or shell has been added. It may come in handy to output variables and run commands on the server:
meteor shell
Meteor apps are Node.js apps. When running a Meteor app with the meteor [run] command, you can configure the NODE_OPTIONS environment variable to start node in debug mode.
Examples of NODE_OPTIONS environment variable values:
--debug
--debug=47977 - specify a port
--debug-brk - break on the first statement
--debug-brk=5858 - specify a port and break on the first statement
If you export NODE_OPTIONS=--debug, all meteor command run from the same shell will inherit the environment variable. Alternatively, you can enable debugging just for one run, with NODE_OPTIONS="--debug=47977" meteor.
To debug, run node-inspector in a different shell, then go to http://localhost:8080/debug?port=<the port you specified in NODE_OPTIONS>, regardless of what node-inspector tells you to run.
To start node.js in debug mode, I did it this way:
open /usr/lib/meteor/app/meteor/run.js
before
nodeOptions.push(path.join(options.bundlePath, 'main.js'));
add
nodeOptions.push('--debug');
Here are additional practical steps for your to attach debugger eclipse:
use '--debug-brk' instead of '--debug' here, because it's easier for me to attach node.js using eclipse as debugger.
add 'debugger;' in the code where you want to debug.(I prefer this way personally)
run meteor in console
attach to node.js in eclipse(V8 tools, attach to localhost:5858)
run, wait for debugger to be hit
when you start meteor in your meteor app folder, you'll see that "debugger listening on port 5858" in console.
On Meteor 1.0.3.1 (update to Sergey.Simonchik answer)
Start your server with meteor run --debug-port=<port-number>
Point browser to http://localhost:6222/debug?port=<port-number>
Where <port-number> is a port you specify.
In your code add a debugger; where you want to set your break point.
Depending on where debugger; is invoked, it will either break on your client or server browser window with inspector opened.
I like to set breakpoints via a GUI. This way I don't have to remember to remove any debugging code from my app.
This is how I managed to do it server side for my local meteor app:
meteor debug
start your app this way.
Open Chrome to the address it gives you. You MAY need to install https://github.com/node-inspector/node-inspector (it might come bundled with Meteor now? not sure)
You'll see some weird internal meteor code (not the app code you wrote). Press play to run the code. This code simply starts up your server to listen for connections.
Only after you press play you'll see a new directory in your debugger folder structure called "app". In there are your meteor project files. Set a breakpoint in there one the line you want.
Open the local address of your app. This will run your server side code and you you should be able to hit your breakpoint!
Note: you have to reopen the inspector and go through this process again each time your app restarts!
As of Meteor 1.0.2 probably the best way for server-side debugging is directly via the new built-in shell: with running server run meteor shell. More info here: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
I am not sure why it was not working for you.
I am able to use it by following steps on console (Mac).
$ ps
$ kill -s USR1 *meteor_node_process_id*
$ node-inspector &
Above steps are mentioned on https://github.com/dannycoates/node-inspector. It is for attaching node-inspector to running node process.
I wrote a small meteor package called meteor-inspector which simplifies the use of node-inspector to debug meteor apps. It internally manages the lifecycle of node-inspector and hence, the user does not need to restart the debugger manually after some files have changed.
For more details and concrete usage instructions take a look at https://github.com/broth-eu/meteor-inspector.
for meteor 1.3.5.2, run
meteor debug --debug-port 5858+n
n is a non-zero number, this will cause node-inspector use 8080+n as web port.
WebStorm, the powerful IDE free for open source developers, makes it much easier to debug server-side.
I've tested it on Windows, and the configuration was painless - see my answer.
A inspector that solve my issues is meteor server console. Here is the process I followed to install it:
In your project folder, add the smart package server-eval:
mrt add server-eval
For Meteor 1.0:
meteor add gandev:server-eval
Restart meteor.
Download crx Chrome extension file from here.
Open extensions page in Chrome and drag crx file to extensions page.
Restart Chrome.
Check the web inspector out to eval server side code:
In comparison with node-inspector, I have a clearer output.
If you prefer to use nodeJS' official debugger you can call NODE_OPTIONS='--debug' meteor and then (on a different shell) node debug localhost:5858.