Developing Software: Configure the MEAN stack files. Package.json

Wow! Things are progressing quickly! Fantastic! We can begin to develop with the generated code previously, but probably we don’t know what most files are for. It’s time to explain the main configuration files we can found in our project structure. Just a reminder, here we have our generated project structure:

blog002webprojectstructure

As a node-based application, it is convenient to start describing what package.json file does for us. You can find more info in npm documentation.

{
“name”: “MyApp”,
“version”: “0.0.1”,
“main”: “src/MyApp.js”,
“scripts”: {},
“dependencies”: {},
“devDependencies”: {},
“repository”: {},
“author”: “luis.vidal”,
“license”: “MIT”,
“bugs”: {},
“homepage”: “https://github.com/luis.vidal/MyApp”,
“engines”: {}
}

I have simplified the file maintaining the main structure. As you can see it is a JSON file and it is useful to provide information to the npm command, allowing to identify the project and manage all project dependencies. More in depth, the information provided by the file is as follows:

  • name: According to the official documentation, name and version fields are the most important things in our package.json because they together form an identifier that it is supposed to be unique. The name field is how we call our project/app/thing.
  • version. A version number that should be pareseable by node-semver.
  • main. It is a module ID that represents the primary entry point to our application. Documentation is not enough clear from my point of view about this field. What I understand is this field is useful when we are building a JavaScript library or reusable code, and this field points to the main JavaScript file which it will run the entire application. If we use this field, what we are saying is people are allowed to use our code through a require(“name_of_library_or_project”) sentence.
  • scripts. We are specifying a dictionary of commands that node can run along the lifecycle of our application. The way we invoke those commands are as follows:

npm run name_given_in_scripts

  • dependencies. This field is usefull to list all our JavaScript dependencies such as third party libraries or modules, or even other local code. All the libraries or modules listed as dependencies will be installed automatically if we use the install option of npm command:

npm install

  • devDependencies. All dependencies listed under this field won’t download and build the external test or documentation framework of the modules or libraries.
  • repository. Just a link to our repository where we have our code.
  • author. Your name as an author of the project.
  • license. License to apply to the project.
  • bugs. An URL to track bugs and/or an email to report the issues.
  • homepage. The url to the project homepage.
  • engines. You can specify the version of node that your stuff works on.

You can find more information about the package.json file here.

We don’t need to include all dependencies manually, we can use npm to search and install interesting modules or libraries and then use it in our code. If we know the name of the module or library to install, or we know part of the name, we can use npm to search that module:

npm search [-l|–long] [search terms …]

Blog003NpmSearch

Once we know the exact name of the module or library to install, we can run the following command to install the dependency into the dependencies filed in package.json:

npm install –save module_name

However, if we want or need to install the dependency into the devDependencies field in package.json, the command to be run is:

npm install –save-dev module_name

Now we can complete our application with more libraries without effort!

One of the things I miss most in ng-fullstack generator is Bower. But Angular 2 is not supported by Bower, so I am not going to install it. Maybe you are wondering why we need Bower if we have npm to deal with our dependencies. The answer is simple: in general npm is used as a dependency manager for back-end projects, that means for the server side, in contrast to Bower, that it is focused in the front-end or client side. Certainly, I didn’t explain what is Bower: it is just a package manager :-P. The main different between them is that Bower is lighter than npm for front-end depedencies because it is optimized for that. That is all. In the next post we will configure Gulp to work with our application easily.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s