As of now I am installing node modules every time for the new angular project. Is it possible to use one projects node modules to other project by configuring any file(like changing the path in any file so it can use that modules)?
From Angular 6, you can generate multiple application in a single Angular project.
https://angular.io/cli/generate#application-command
applications generated by Angular cli command stay in same workspace and share node_modules.
For example, if you want to generate app my-project:
ng generate application my-project
If its dependencies are not different from previous one, you can use --skipInstall=true option with ng generate command.
And ng serve it with --project option:
ng serve --project=my-project
First off I was shocked to see that this is actually a thing that some people are doing - see: https://github.com/nodejs/help/issues/681
However I would advise against it.
The idea behind each project having its own node_modules folder (and package.json) is that each of your projects should specify its own dependencies (including specific versions) which is a good thing for stability, predictability, reproducibility, etc. of your various projects. Here's a pretty good write-up on the node dependency model: https://lexi-lambda.github.io/blog/2016/08/24/understanding-the-npm-dependency-model/
Now if you're talking about a local module (that you created yourself), you can have a look at https://docs.npmjs.com/cli/link.html
My projects uses a /server folder for my backend code and /react-ui for my client side code. There's a package.json in each folder. I can run test separately in the cmd line, but I would like to run both at the same time. I know about the multi projects feature of jest, but it doesn't seem to work with create-react-app. I'm trying to setup jest with babel as if I was not using create-react-app, but it seems like the wrong approach considering jest is already setup in CRA.
My current setup runs from the /server jest installation. With projects: ['<rootDir>', '<rootDir>/../react-ui']. The jest documentation isn't clear how I could direct it to run npm test in /react-ui
My only goal is to be able to watch both at the same time and I would like to not eject from CRA.
You can have (gulp) scripts on the main level that run each tests separately, but using same configs.
This blog post I found today shows something like this for React. He starts with a node project and then within that he creates a react project in a subfolder. Plus some proxy config stuff.
I wasn't this clever about 10 days ago but here's what I did for Vue.
Created a Vue project
Built it for production
Added a package.json and a server.js in the dist folder created by the Vue build process
The package.json contains these two lines: "postinstall": "npm install express" and "start": "node server.js"
And voilá! Express listens on 8081 internally (but translated to 80/443 by Heroku) and I can get a response in the Vue frontend from the Node backend. So technically it works. But I don't feel it's a nice solution. Kind of messy, smells like desperate hacking and tinkering.
The point is, of course, to avoid having two different Heroku pods for an otherwise small, almost weightless personal project. One for the frontend part and one for the backend.
Can you show me anything better?
You could use a vue-cli project
Then you create a subfolder with your express project and start your script (in package json) like :
npm run vueproject && npm run expressproject
and your both projects will start together.
You have to :
Use a different port for each project.
Install dependencies of the expressproject in the
vueproject package.
Know that's not a good practice to do like this.
I have an extensive MochaJS test suite for my ExpressJS / NodeJS API. The test suite includes creation of objects and removal of those same objects from the database.
Currently, all of my regression tests are passing in my development environment. We'd like to be able to run the same test on the staging environment that has data objects that were migrated and not created after the new code was deployed.
How do we run our mocha tests from the server?
Currently, I use the following command to run my tests, locally:
foreman run node node_modules/mocha/bin/mocha
Thanks in advance for any help!
You can probably leverage the package.json scripts:
https://docs.npmjs.com/misc/scripts
If heroku uses a simple npm install to install your package, you can define a prepublish script which runs mocha. It's as simple as defining this in your package.json:
"scripts": {
"prepublish": "mocha"
}
Don't worry about mocha not being installed globally, npm install will add the node_modules/.bin folder to the PATH environment variable during installation.
Our team decided to go the route of using continuous integration as the mechanism for running server side tests. Two birds with one stone!
We're using CircleCI to make that happen.
We're now passing the supertest library the app module rather than a URL. This allows the endpoints to be called at the HTTP layer by supertest.
Hope this helps anyone else looking at similar alternatives!
I am new to Node.js programming and I have recently created a sample working web application using (express, backbone & other complimentary view technologies, with mongoDB). Now i am at a point where I want to deploy the same on a staging environment and I am not sure how to package this application and distribute the same. [I can take care of mongoDb and setting it up seperately]
I am from Java world and in there we create jars for reusable libs and war/ear packages for web applications which is deployed in a servlet container. Now in this case since node.js itself acts as a web container as well, how do i package my webapp?
Is there any standard format/guidelines of packaging node webapps built using express? (Is there a similar jar/war packaging systems for node apps?)
How do I deploy it once packaged? Would it become an exe, since it is also its own container?
PS: As of now I am thinking of just manually copying all the required source files into the staging environment and run npm commands to download all dependencies on that machine and then use 'forever' or some other mechanism to run my server.js. (Also, add some sort of monitoring, just in case app crashes and forever fails) I am not sure if that is the right way? I am sure there must be some standardized way of addressing this problem.
Deploying Node.js applications is very easy stuff. In maven, there is pom.xml. Related concept in Node.js is package.json. You can state your dependencies on package.json. You can also do environmental setup on package.json. For example, in dev environment you can say that
I want to run unit tests.
but in production;
I want to skip unit tests.
You have local repositories for maven under .m2 folder. In Node.js, there is node_modules folder under your Node.js project. You can see module folders with its name.
Let's come to the grunt part of this answer. Grunt is a task manager for your frontend assets, html, javascript, css. For example, before deployment you can minify html, css, javascript even images. You can also put grunt task run functions in package.json.
If you want to look at a sample application, you can find an example blog application here. Check folder structure and package.json for reference.
For deployment, I suggest you heroku deployment for startup applciations. You can find howto here. This is simple git based deployment.
On project running part, simply set your environment NODE_ENV=development and node app.js. Here app.js is in your project.
Here is relative concept for java and nodejs;
maven clean install => npm install
.m2 folder => node_modules(Under project folder)
mvn test => npm test(test section on package.json)
junit, powermock, ... => mocha, node-unit, ...
Spring MVC => Express.JS
pom.xml => package.json
import package => require('module_name')
There is no standardized way, but you're on the right track. If your package.json is up to date and well kept, you can just copy/zip/clone your app directory to the production system, excluding the node_modules.
On your production system, run
npm install to install your dependencies, npm test if you have tests and finally NODE_ENV=production node server.js
Some recent slides I considered to be quite helpful that also include the topic of wrappers like forever, can be found here.
Hope this might be helpful for somebody looking for the solution,Packaging of Node js apps can be done using "npm pack" command.It creates a zip file of your application which can be run in production/staging environment.
Is there any standard format/guidelines of packaging node webapps
built using express? (Is there a similar jar/war packaging systems for
node apps?)
Yes, the CommonJS Packages specification:
This specification describes the CommonJS package format for
distributing CommonJS programs and libraries. A CommonJS package is a
cohesive wrapping of a collection of modules, code and other assets
into a single form. It provides the basis for convenient delivery,
installation and management of CommonJS components.
For your next question:
2. How do I deploy it once packaged? Would it become an exe, since it is also its own container?
I second Hüseyin's suggestion to deploy on Heroku for production. For development and staging I use Node-Appliance with VirtualBox and Amazon EC2, respectively:
This program takes a Debian machine built by build-debian-cloud or
Debian-VirtualBox-Appliance and turns it into a Node.js "appliance",
capable of running a Node application deployed via git.
Your webapp will not become an exe.
few ways to approach this:
Push your code into Git repository, excluding everything that isn't your code (node_modules/**), then pull it in your staging environment, run npm install to restore all dependencies
create an NPM package out of it , install it via npm in your staging environment (this should also take care of all of the dependencies)
manual copy/ssh files to your staging environment (this can be automated with Grunt), than restore your dependencies via npm
I used zeit's pkg module. It can create cross platform deliverables for linux/win/macos. Actually used it in production and works fine without any issues.
It takes in all the js scripts and packages it into a single file.
The reason I used it is because it helps in securing your source code. That way in production at customers environment they will have access to application but not the source code.
Also one of the advantages is that at production environment, you do not actually need to have the customer install node.js as the node binaries also get packaged inside the build.
https://www.npmjs.com/package/pkg