I am a beginner to mean.
I have followed the following steps to create meanjs app :
installed node v0.12.7
npm install -g bower
npm install -g grunt-cli
npm install -g yo
npm install -g generator-meanjs
cd C:\Users\SHIVAM\Desktop\MyApp
yo meanjs
MyApp folder containing mean directory created
Error occured on yo meanjs 1
Please provide a solution . I am struck at the first phase. I need to get started as sson as possible .
Version 0.4.* has different folder structure. The tutorial you are following is probably using earlier version of meanjs. You can find the new structure here-http://www.bossable.com/954/version-0-4-0/ She has compared the structure with the older one. I was going through the same problem. Follow these tutorials, it will be of great help.
The following directories have been changed in the 0.4.* versions of Meanjs; 0.4.2 is still unstable. 0.4.0 and 0.4.1 is recommended for beginners to get on MEAN.
-New files have been added
1) gulpfile.js-Gulp is relatively faster than grunt because gulp focuses on code rather than cofiguration. It uses node.js’ streams, and executes faster, since it does not open/close files, or create intermediary copies all the time. The lack of any up-front configuration, especially, specifying a source and destination is noticed immediately in this file.
2) protractor.conf.js-Support file for end-to-end testing in angularjs applications. (Pretty Neat.)
The app folder is removed, which is the major concern for the noobs trying their hands on MEANjs following the older tutorials. Controllers,views, models are now moved into a separate folder called modules which was previously in the public folder.
You can explore modules/core/server and modules/user/server of your project
Addition of client, server and test in modules/core and modules/user folder. All the client side angular will now be in the modules/core/client making it easier to access all services and directives of different modules of the application at one place. And all the backend or server-side files goes to modules/core/server.
public/application.js and public/config.js are now config.js and init.js in modules/core/client/app folder.
config folder is split and new folders assets and lib are added.
The previous env folder have been split into env and assets. All the references, mongodb port, session keys goes to the environment(env) whereas new libraries we are defining into our project goes to assets. For instance new css, sass or less reference will be defined into asset/default.js. config.js and init.js are merged into one file config/config.js.
lib contains express.js, mongoose.js and socket.io.js.
node_modules is pretty much exactly the same as the previous versions of meanjs.
These are the major changes in the folder structure. New models and controllers are added into the modules/users/server according to your application, just so you don't get lost while developing your project.
Related
I am quite new to programming and today decided to attempt and create a node.js and puppeteer project with the purpose of scraping website into a .txt file. I ran into issues straight away since for the most part I have no idea what I'm doing. After installing node.js and puppeteer, I was guided by some videos and articles I found to create my first project. In the command prompt using mkdir and later cd I was able to create and access the new directory, but I started running into problems with npm init. It only places the file package.json in the repository, but there isn't a package-lock or node_modules file anywhere. No idea what they do but thought this was a problem. When I open cmd and try to run the app by typing node app.js it returns Error: Cannot find module 'C:\Users\emili\app.js' along with some other gobble. What should I do, to be able to run the simple application I wrote?
It seems that you are missing some key knowledge on how NodeJS works, but in order to fix your issue (for now), you will need to take a few steps.
First, in your working directory (where the package.json is), you'll need to install your modules.
Run npm install puppeteer. This will do two things, create the node_modules folder and create the package-lock.json file.
Create a file named app.js (either manually or by running the command touch app.js) in your working directory, and put the following content inside of it:
console.log('Hello, World!');
Save the changes to app.js and then run node app.js in your terminal. You should see Hello, World! output to the terminal.
The reason npm install puppeteer created the node_modules folder and the package-lock.json file is because they weren't needed beforehand.
When you run npm install PACKAGE_NAME, you're installing a module (otherwise known as a package), thus it creates the node_modules folder so that it will have a place to put the module so that your code can access it. It also creates the package-lock.json file, which is used to track the module versions inside of your project.
With this information, I request you go back to the tutorial you were originally following and try going through it again and attempting to understand each of the core concepts before writing any real code.
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
What is the best practice for deploying a nodejs application?
1) Directly moving the node_modules folders from the development server to production server, so that our same local environment can be created in the production also. Whatever changes made to any of the node modules remotely will not affect our code.
2) Run npm install command in the production server with the help of package.json. Here the problem is, any changes in the node modules will affect our code. I have faced some issues with the loopback module (issue link).
Can anyone help me?
Running npm install in production server cannot be done in certain scenario (lack of compiling tools, restricted internet access, etc...) and also if you have to deploy the same project on multiple machines, can be a waste of cpu, memory and bandwidth.
You should run npm install --production on a machine with the same libraries and node version of the production server, compress node_modules and deploy on production server. You should also keep the package-lock.json file to pinpoint versions.
This approach allows you also to build/test your code using development packages and then pruning the node_modules before the actual deploy.
Moving node_modules folder is overkilled.
Running npm install might break the version dependencies.
The best approach is npm ci. It uses the package_lock file and installs the required dependencies without modify the versions.
npm ci meant for continuous integration projects. LINK
I am an ASP.NET Core developer but I recently started working with Node.js apps. For me this was one of the challenges you mentioned to move the node_modules folder to production. Instead of moving the whole folder to production or only running the npm install command on production server, I figured out and tried a way of bundling my Node.js app using Webpack into a single/multiple bundles, and I just got rid of the mess of managing node_modules folder. It only picks up the required node_modules packages that are being used/referred in my app and bundles up in a single file along with my app code and I deploy that single file to production without moving the entire node_modules folder.
I found this approach useful in my case but please suggest me if this is not the correct way regarding the performance of the app or if any cons of this approach.
Definitely npm install. But you shouldn't do this by your own hand when it comes to deploying your app.
Use the tool for this like PM2.
As for your concern about changes in packages, the short answer is package-lock.json.
My guess is that by asking this question you don't really understand the point of the package.json file.
The package.json file is explicitly intended for this purpose (that, and uploading to the npm registry), the transfer of a node package without having to transfer the sizeable number of dependencies along with it.
I would go as far as to say that one should never manually move the node_modules directory at all.
Definitely use the npm install command on your production server, this is the proper way of doing it. To avoid any changes to the node_modules directory as compared to your local environment, use the package lock file. That should help with minimising changes to the source code in node_modules.
I mean no bad intent by saying this
This must be a commonly solved problem, but I cannot find a whole lot on Google/SO so far.
When we run npm install and fetch say 50+ packages including devDependencies as well as runtime dependencies, npm creates node_modules (if needed) and adds each of those packages inside that folder. This means we end up with thousands of extraneous files included under node_modules. Each of those packages contains their own package.json, README.md, minified files, source files, etc. Our application really only cares about jquery.js (for DEV) and jquery.min.js (for PROD), so it seems to be a waste to include all of these other files into our build and therefore our web server.
Is there a standard when it comes to handle these npm packages in a way so that we simply expose ONLY the necessary files to the user? I imagine many people have this kind of issue but I don't see any built in npm constructs that allow us to do this easily.
See below.. the yellow highlighted files are the only files we really care about in Production, but we get all these extra files as well including the source code.
The most common solution consist of bundling your application on a different machine and then expose the built artefacts on production server.
There are a lot of great JS bundlers out there. The ones I have personally used are Browserify, Webpack, and Rollup. All amazing tools.
The main idea consists of writing your application in a Node environment and then bundle it to make it readable to the browser.
For simpler projects I find Browserify a very good compromise between power and ease of configuration. But it's a matter of taste, at the end. :)
Base on what I read about npm install documentation I do not think there is a option to manipulate the installation in the way you want. The packages will install the way the package author decides to package it, sometimes minified sometimes not.
Having said that, you should look for third party solutions like modclean which does exactly what you want post package installation. Run this command in the root of your project directory
npm install modclean -g
modclean
As long as your test coverage is good, ModClean would be perfect for your need.
Edit the package.json file and remove all the unnecessary dependencies then do
npm install --save
By doing this, it will create a local node_modules folder and only download the necessary packages into it (not the global node_modules folder)
Keep in mind, by default, node checks for local node_modules folder. If it couldn't find it, it will use the global folder.
Also, you don't expose all the packages in the node_modules folder. In fact, they will not be used unless you require(); them in the node.js file
EDIT:
For jQuery to work in Node, a window with a document is required. Since no such window exists natively in Node, one can be mocked by tools such as jsdom. This can be useful for testing purposes. https://www.npmjs.com/package/jquery
require("jsdom").env("", function(err, window) {
if (err) {
console.error(err);
return;
}
var $ = require("jquery")(window);
});
So jquery module do things a bit differently behind the scene for node.js comparing to the regular front-end jquery.
It requires jsdom so you will have to download that as well from here https://github.com/tmpvar/jsdom
I've been using Node.js and npm for a few weeks with great success and have started to question the best practice for installing local modules. I understand the Global vs Local argument, however, my question has more to do with where to place a local install. Let's say that I have a project located at ~/ProjectA/ which is version controlled and worked on by multiple developers. When initially playing with Node.js and npm I wasn't aware of the default local installation paths and just simply installed the necessary modules in a default terminal which resulted in a installation path of ~/node_modules. What this ended up doing is requiring all the other developers working on the project to install the modules on their own machines in order to run the application. Having seen where some of the developers ran npm install I'm still really surprised that it worked on their machines at all (I guess it relates to how Node.js and require() looks for modules), but needless to say, it worked.
Now that the project is getting past the "toying around" stage, I would like to setup the project folder correctly. So, my question is, should the modules be installed at ~/ProjectA/node_modules and therefore be part of the version controlled project files, or should it continue to be located at a developer-machine specific location...or does it not really matter at all?
I'm just looking for a little "best-practice" guidance on this one and what others do when setting up your projects.
I think that the "best practice" here is to keep the dependencies within the project folder.
Almostly all Node projects I've seen so far (I'm a Node developer has about 8 months now) do that.
You don't need to version control the dependencies. That's how I manage my Node projects:
Keep the versions locked in the package.json file, so everyone gets the same working version, or use the npm shrinkwrap command in your project root.
Add the node_modules folder to your VCS ignore file (I use git, so mine is .gitignore)
Be happy, you're done!