I'm using coffeescript for my current node.js project, starting the project with the following command (inside my project folder)
coffee app.coffee
Which starts the node application. I am, however, at a loss as to how node.js can interact with the coffeescript - is it compiled to a temporary folder?
Do this:
cat `which coffee`
And you'll see that coffee is actually a node script, which compiles your .coffee file and then runs it.
Related
it is generic question.
I know that if I have java project I can run mvn clean install and it will build the project and the artifacts will be jar or war in target folder
if U have node.js application How I can build it ? I know that I have package.json that could run with npm install and the artifices are node modules but I guess there is a way to build the result of the node application . what is the type of the result ?
How to build node js application?
You don't really "build" a regular node.js application. There is no compile step. There is no separate executable. Whatever your main entry Javascript file is, you would just run it with node main.js and everything else will be loaded from there as your Javascript files load other modules. The Javascript interpreter will compile your JS files on the fly as they are encountered. If there is a syntax error when the file is loaded, it will throw an exception at that time.
For the simplest possible hello world application, you'd just put this into a text file named main.js:
console.log("Hello World");
And, then type this at the command line:
node main.js
And, you would see your output in the console. No compile step. No build step.
There are transpilers and there are packagers that can do special things, but none of that is needed for a regular node.js app.
but if I write something wrong in the code.How i can check it for example like mvn
Javascript is an interpreted language (like PHP, Python, Perl, etc...), not like Java. You will likely get a run-time error when you run your app if you write something wrong in the code. Of course, there are all sorts of tools that will check things for you before you run your code (such as linters), but Javascript does not work like Java in that regard.
If you want a "typed" and "checked" language, then you can use TypeScript which is "compiled" into Javascript that node.js can run and the compile step for TypeScript will check your syntax for you, enforce data typing, etc...
I am learning building Node modules and packaging it with Electron. I've successfully built an module out of a CPP file and can run it with node. However, to run it with Electron I need to rebuild Electron. There are instructions out there, for example:
https://github.com/electron/electron/blob/v0.37.2/docs/tutorial/using-native-node-modules.md#using-native-node-modules
https://github.com/electron/electron/issues/2330
Here I have an addon.node file after running node-gyp build. I can reference it in the node application from anywhere: var addon = require('.Release\addon'); and it works fine. However, when I build Electron with it I don't understand where to put the .node file so that it is used in the build. Before I run node_modules\.bin\electron-rebuild (see bullet point 1 link above) where should I put the addon.node file? Is it right to say that before I even test it withing Electron (with console.log or something) I need to run electron-rebuild. Is there a step that I missing that I need to take from having the addon.node file to starting to build it into Electron?
Thank you.
I remember hearing from someone that you can simply type in a command to compile a meteor.JS app into a node.JS app, and then deploy it as a node.JS app. Is that correct? Also, does that mean I can build a completely node.JS app by first building it in Meteor, and then using a command to compile it into node? If so, how can I do that?
You can use tool for doing that:
https://github.com/onmodulus/demeteorizer
Tutorial:
http://blog.modulus.io/demeteorizer
I believe you are looking for meteor bundle (See documentation). Meteor bundle constructs a tar.gz file from your meteor application. Once extracted, you should be able to run main.js in the extraction directory and your application built with meteor will run as a standard node application.
For clarification, here are some steps to bundle and run your node application built with meteor.
Within your meteor application directory, run:
meteor bundle appName.tar.gz
Then, unpack the bundle that meteor creates:
tar -xvzf appName.tar.gz
If the proper version of node is installed, you should be able to set your environment variables, and run the application.
export MONGO_URL='mongodb://localhost'
export ROOT_URL='http://myApp.com'
export PORT=5000
And finally, run your application. In the directory that you extracted the tar.gz file to, run:
node main.js
With the default version of sails on npm (v.9?) --linker works ok i.e. creates /linker folder. I can copy js, css files to assets/linker/ and they appear in layout.ejs automatically.
I now have sails v0.10 installed both locally and globally. Using Node V0.10.25.
I created a new sails project using:
sails new project_name --linker
but no /linker folder is created.
I had to create /.tmp as it did not exist
I had to create /.tmp/public/linker/ to put /js & /styles
and add them manually into layout.ejs
I renamed Gruntfile.js and my program still works thus Gruntfile does nothing in the program.
Sails v0.10 no longer uses the linker folder--it was just causing confusion. If you have the linker option enabled, then any assets under your assets folder will be copied over to your .tmp/public folder by Grunt when Sails is lifted. The public folder will be created by Grunt as necessary. The grunt-sync task will then keep the folders synced as long as the program is running.
Sails projects are not dependent on Grunt, so renaming the Gruntfile (or removing it completely) won't stop the program from working, but that doesn't mean it's not doing anything when it's there! To see what Grunt is up to, you can lift Sails with sails lift --verbose.
As an add-on to sgress454's answer, the reason a .tmp folder is created is so that files like the ejs and less files can be compiled into formats that your browser will understand. It's similar to the way that when you compile Java, it converts to Java bytecode (just an analogy, definitely not the same process).There doesn't necessarily have to be any .tmp folder when you're not running the server though; this is something Grunt creates and is what the browser reads from. Hope this clarifies things a bit more.
I have recently started learning nodeJS. Being a long-time coffeescript lover I naturally decided to use it along with node. Writing long-running processes with node I found myself restarting the program frequently. After a quick google I found node-supervisor. Node-supervisor simply watches the current directory for file changes and restarts your app for you automatically.
Before I started using supervisor I was using coffeescript with the --watch option to automatically recompile my coffescripts when they changed.
So the problem is this, supervisor and the coffeescript recompiler don't play nice together.
First I run coffee --compile --watch .
Then in a new terminal I run supervisor app.js
After that supervisor keeps restarting my app forever, even when there has been no changes to the source files.
So the question is this, what is your workflow for working with nodeJS and CoffeeScript?
What you are doing is some kind of redundant.
Here are some hints:
after installing CoffeeScript you have an executable called coffee so you can do (no need to compile your coffee-script files):
coffee yourfile.coffee
how to combine this with supervisor?
if you would have read the Readme on the Github page you would have noticed that supervisor can execute CoffeeScript files, too. All you need to do is:
supervisor yourfile.coffee