I am rereading this tutorial
https://devcenter.heroku.com/articles/getting-started-with-nodejs#introduction
to polish my understanding of Node.js/Heroku.
There is a section called Define a Procfile.
But when I go to see my own apps to check what is inside this file.
I see that a number of apps (not all) have no such a file and are working fine.
So, what is going on? When is Procfile necessary? What happens if there is none?
When is it better to have one?
To help you get started, Heroku will try to automatically detect the type of your app and start it appropriately, even when it doesn't have a Profile (see example here - http://blog.taylorrf.com/blog/2014/12/15/heroku-default-server/ ).
For example in Node, if you have an index.js file and a package.json file, it's probably a node app that could be started with node index.js.
While convenient, this is considered bad practice, because:
Heroku may change how they auto detect apps in the future, breaking your deployment.
You might be missing out on some configurations / optimizations by doing so (see article linked above).
Related
I've been going through the documentation at https://bazelbuild.github.io/rules_nodejs/ in order to put together a small web based application. I've got babel building the JS code, and http_server serving it, and ibazel watching it, and everything is working as expected: when I make a change, ibazel notices it and restarts the http_server rule.
The next thing I wanted to look at is getting autoreload in the browser so that the browser would automatically refresh when the change was compiled. My understanding is that this requires the http server to not be killed by ibazel, but instead to stay up and trigger a refresh via the ibazel_live_reload mechanism. I believe that http_server doesn't support this, but ts_devserver is explicitly mentioned in several places. However, ts_devserver doesn't seem to be maintained anymore (although I did find a devserver EXE in the npm package, there isn't a bazel rule that I saw to use it).
Is there a third party live development server that supports the ibazel reload mechanism - or am I missing something completely obvious?
Disclosure, I'm a core maintainer on rules_nodejs
As of rules_nodejs v3.0.0, ts_devserver has been renamed to concatjs_devserver to try and better namespace it (it has little to nothing really to do with Typescript). Its docs can be found here.
Note though that the concatjs_devserver comes with some compatibility gotchas, all dependencies have to be in named AMD/UMD or goog.module format for example, and may be tricky to use unless following the rest of the google3 toolchain.
We've (as the maintainers of rules_nodejs) tried not to wrap an existing devserver and publish it as of yet for various reasons, but it's something that has come up in discussion. I'm currently investigating some options in this space.
I'm not aware of any published devservers that currently support the ibazel protocol, there is a wrap of browsersync in the Angular Components repo which you may find useful.
So, here's the situation. I've recently "inherited" a decent sized web application, built using React (and Redux) and compiled using webpack/babel. Two files are generated, app.js and server.js, both of which run on Node.
The original developer of the project was mostly "winging it" on the back-end (server.jsx and so on -> server.js), using console.log to figure out what was going on, and then just gut feeling the fix. That works on a smaller scale, but will be problematic in time.
I can debug both of the actual files, but only app.js is ever mapped properly, meaning I can debug the source code. This also affects hot loading. Any breakpoints related to server.js will only trigger in the actual server.js file in IntelliJ, which is a completely unreadable mesh, so that's not really an option.
I'm using IntelliJ (WebStorm for those of you who only use the web version), and I've tried to use every single guide I've come across to set it up, which usually comes down to babel-node, babel watchers or webpack-dev-server. The current app.js is run using webpack-dev-middleware, and debugging it in Chrome works like a charm, but for some reason it always just bundles in server.js and then fires when ready (in these Star Wars times).
I understand that it's hard for Chrome to get access to server.jsx, but surely there must be some way of setting up IntelliJ (or WebStorm) to do so? I'm more used to a Java or C# server side, so I'm a bit baffled that this isn't a straight forward, out-of-the-box option. Or maybe it is, and the initial setup is lacking?
PS. When using React (and Redux) as both the front and back end on Node, is it meant to be virtually impossible to distinguish between the two? Server.jsx is fairly obvious, but there are quite a few duplicated javascript files and dependancies, especially related to handling/building the Redux store.
I'm using Electron to build a native application, based on existing code (developed with Electron v0.26.1). I'd like to use features available on more recent versions of Electron, so I changed the version number in package.json to v0.36.9 (the most recent one so far) and reinstalled its dependencies.
Now, I fully expected the applicaton to break when running npm start, and indeed it does, but I didn't expect the error message to be so uninformative:
Error opening app
The app provided is not a valid Electron app, please read the docs on how to write one:
https://github.com/atom/electron/tree/v0.36.9/docs
Error: Cannot find module '/home/user/electron/myapp/build'
I'd appreciate if it would say why it is no longer a valid Electron app, give any sort of stack trace, or file causing the issue.
Running npm start did create a build directory like before, which contains several files, just like before the upgrade. From the way it's worded, I cannot know if the Cannot find module message is the cause of the error, or the consequence. And if it is the cause, I have no idea of who or what is requiring such module, since before the upgrade this had never happened.
I tried "standard" debugging techniques, like running npm start --debug (the flag exists, but is not useful in this situation), npm rebuild, reading the Electron FAQ, looking for any *.log files (none to be found), and looking for occurrences of require('build') or something similar (no such occurrences). Nothing helped.
How can I get any information at all about why this is failing? Every programming language/build system I know of would at least output the source file where the error occurred, and possibly more information.
In your app's package.json there probably something like:
"scripts": {
"start": "electron /home/user/electron/myapp/build"
}
That's the command that will be executed when you run npm start, so fix the path in there to point to the .js file that contains your app entry point.
Well, after bisecting changes here and there, and following Vadim Macagon's advice to look further into package.json, I found out that the following change was responsible for the complete failure:
Changing "fs-jetpack": "^0.6.4" to "fs-jetpack": "^0.7.1"
Now, unfortunately I still have absolutely no idea about why that happened, or how I could have possibly found it out other than blindingly changing settings here and there.
This is not the answer to my question (I'd still like helpful information about how to debug Electron apps to avoid similar problems in the future), but it does allow me to keep working. That is, if I decide to keep using Electron, which I'm no longer sure it's a good idea.
Edit: There is at least one related issue on Github, but it has been closed and the issue has not been resolved.
I'm trying out Node.JS for the first time using MEAN.JS as a starting point. When testing on localhost, everything looks OK. However, when deploying to https://raichu-com.herokuapp.com/, I get a blank page (the header menu flashes for a moment, then goes away).
I don't see any error in my logs, and the database seems to be connected properly (users and sessions collections are created). What could probably be the issue here?
I compared local and cloud Sources, seems like there's a little difference:
Also, while irrelevant to the question, it'd be incredibly helpful if you could name me some (other) examples of cloud providers for Node.JS that you think are (more) affordable and easy to use.
teamtreehouse also has a good tutorial on getting node to work on Heroku
it lists steps like
specify the version of node in your package.json,
include a Procfile,
etc...
In Heroku var config add
NODE_ENV
development
Seeing how node.js is ultimately javascript, shouldn't changes to any files be seen when trying to run the app command? I've forked the yuidocjs repo on github and am trying to work my way through my local build, but for some reason my minor changes do not get picked up. I'm new to node.js so I'm not really sure what the exact conventions are.
In node.js when you require a file the source code gets interpreted. It's considered good practice to require all code when you start the server so all the code gets interpreted once.
The code does not get re-interpreted whenever you run it though.
So changes are not instantaneous.
To help you out, try supervisor which does hot reloading of the server on code changes.
It is possible to make instant changes happen by re-interpreting source code but that is not the default action. Generally you should just re-start the server.
Also see nodemon which will automagically reload changed files under it's authority.
EDIT
Rereading your question, it appears you are asking about the following scenario:
Run app to test
Quit app to refactor js code
Restart app
And you're asking why your changes do not appear at step 3?
If this is the case, you are seeing something very strange which might be related to how and from where files are being required.
In node, run:
console.dir(require.paths);
To see where node is looking for any resources you are requiring. If there is a copy of the file you're changing in any of the paths listed which is not the file you're editing, this would explain your problem.