Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit ae922d4

Browse files
sethvincentsethvincent
committed
add npm scripts chapter
1 parent eaeb6b6 commit ae922d4

13 files changed

+1125
-45
lines changed

‎book.md‎

Lines changed: 179 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -1613,6 +1613,182 @@ git push origin gh-pages
16131613
```
16141614

16151615

1616+
# Package managers for browser code: what should I use?
1617+
1618+
When should I use npm, bower, or component for managing client-side code?
1619+
1620+
To start: always use one of them. The old days of downloading js/css libraries one by one and updating them manually are totally over, and that's exciting. Using a package manager for front-end code means we can easily download libraries, keep track of versions, and ease dependency management.
1621+
1622+
But we still have too many options for how to manage our client-side code. Beyond npm, bower, and component there are still many other options, but those three seem to be settling in as the most widely adopted.
1623+
1624+
## And all three are quite different:
1625+
1626+
### npm
1627+
npm nominally started out as a package manager for node, but now is used for any javascript, and along with a tool like browserify it's easy to use npm packages and node-style modules in the browser. It's not super useful for css libraries – but it's easy to imagine a tool (built on something like brfs) that could make bundling css npm packages super pleasant.
1628+
1629+
### bower
1630+
bower is a clear hero of client-side code: it's great for both css and javascript. It's easy to manage dependencies – even if those dependencies don't have a config file for bower. You can install a file or git repository as a dependency alongside packages in the bower registry. Bower doesn't make any assumptions about how you build or deploy code, so it is compatible with amd modules.
1631+
1632+
### component
1633+
component is a tool with a more focused and defined goal than npm and bower. It uses common js style modules. Each component may contain javascript, css, fonts, and images. Some javascript-only components can also be used in node.js. See the [Component FAQ](https://github.com/component/component/wiki/F.A.Q) for more details.
1634+
1635+
## When I use npm for browser code:
1636+
Games. There's been a lot of interesting activity in javascript game development in the node.js community using browserify. voxel.js is one of the biggest examples, with a goal of creating minecraft-like games in the browser. See the work of these people for examples:
1637+
1638+
npm/browserify will also be useful for creating applications that might share javascript code on the server and the browser. This approach also works well when the javascript requirements for the client-side are minimal, or if you prefer to write client-side code in a node style.
1639+
1640+
## When I use bower for browser code:
1641+
When the project requires a front-end framework like backbone, angular, or ember, I use bower as the package manager. It's currently the best way to package arbitrary dependencies of a javascript application. Typically using bower means that I am also using the build tool grunt.
1642+
1643+
## I don't really use component yet.
1644+
I really want to. It seems like there's some great work happening around component. I expect that there will be instances when I'll want to use some of the available components. But when that happens, I'll probably need to figure out a way to integrate component with bower or npm/browserify.
1645+
1646+
## Use all three at once!
1647+
It's possible to use packages from both bower and component while using browserify!
1648+
1649+
Check out this great guide for using components, bower packages, amd modules, and even global variables with browserify: http://dontkry.com/posts/code/browserify-and-the-universal-module-definition.html
1650+
1651+
1652+
# Introduction to npm scripts
1653+
1654+
As a simple alternative to using more complicated build tools like Gulp or Grunt, you can use npm scripts to run tasks like testing your JavaScript code or running a development server.
1655+
1656+
First create a package.json file if you don’t have one already:
1657+
1658+
```
1659+
npm init
1660+
```
1661+
1662+
This will ask you a few questions about your project. Answer the questions and you’ll get a package.json file.
1663+
1664+
It will look similar to this:
1665+
1666+
```
1667+
{
1668+
"name": "example",
1669+
"version": "0.0.0",
1670+
"description": "example project",
1671+
"main": "index.js",
1672+
"scripts": {
1673+
"test": "echo \"Error: no test specified\" && exit 1"
1674+
},
1675+
"author": "sethvincent",
1676+
"license": "BSD"
1677+
}
1678+
```
1679+
1680+
You can revise the `main` property to be whatever makes sense for your project. If this won’t be released on npm, you might not even need `main`.
1681+
1682+
Now, check out the scripts section. There’s already test, but it needs to have an actual command associated with it. Change the error message to whatever command you use to run tests.
1683+
1684+
I might change it to something like this:
1685+
1686+
```
1687+
"scripts": {
1688+
"test": "node test.js"
1689+
}
1690+
```
1691+
1692+
To run the tests, you run this command:
1693+
1694+
```
1695+
npm test
1696+
```
1697+
1698+
That doesn’t gain a whole lot of simplicity over just running node test.js, but when the command for running tests is more complicated, being able to run npm test instead helps out a lot.
1699+
1700+
## A development server
1701+
Let’s use a simple development server designed to work with [browserify](https://github.com/substack/node-browserify) named [beefy](https://github.com/chrisdickinson/beefy).
1702+
1703+
Install beefy as a development dependency:
1704+
1705+
```
1706+
npm install beefy --save-dev
1707+
```
1708+
1709+
Add a start script to your package.json:
1710+
1711+
```
1712+
"scripts": {
1713+
"test": "node test.js",
1714+
"start": "beefy index.js:bundle.js --live"
1715+
}
1716+
```
1717+
1718+
Now we start to see how npm scripts can be useful. That beefy command is just long enough that it’s useful to have npm start as an alias for our development server.
1719+
1720+
Just to prove it works, create an index.js file and pop in a short console.log statement:
1721+
1722+
```
1723+
console.log('it works!');
1724+
```
1725+
1726+
Now run npm start, and you’ll see output that looks like this:
1727+
1728+
```
1729+
> [email protected] start /Users/sethvincent/workspace/bookery/tmp
1730+
> beefy index.js:bundle.js --live
1731+
1732+
listening on 9966
1733+
```
1734+
1735+
Now you can go to http://localhost:9966 to see if the console.log statement worked.
1736+
1737+
You might be saying, “Hey, I don’t have an index.html file. What is this magic?”
1738+
1739+
If there isn’t an index.html file in the directory you’re in when you run beefy, it’ll serve a really basic index.html file so your javascript can run.
1740+
1741+
Add another statement to your index.js file:
1742+
1743+
```
1744+
document.write('served.');
1745+
```
1746+
1747+
You’ll see that without reloading the page the string served is now displayed in your index.html file.
1748+
1749+
## Arbitrary scripts
1750+
There are a few default script names you can hook into and run your own scripts using npm aside from test and start. To see a list of them, read the npm-scripts documentation.
1751+
1752+
You can also run arbitrary scripts. Let’s add a script named +pizza+.
1753+
1754+
```
1755+
"scripts": {
1756+
"test": "node test.js",
1757+
"start": "beefy index.js:bundle.js --live",
1758+
"pizza": "node pizza.js"
1759+
}
1760+
```
1761+
1762+
Let’s pretend pizza.js automates the process of ordering a pizza online from your favorite pizza place.
1763+
1764+
To run the command we prepend our script name with run, like this:
1765+
1766+
```
1767+
npm run pizza
1768+
```
1769+
1770+
You can add whatever scripts you want. You can even set up a master script that runs a bunch of your npm scripts! Chek it out:
1771+
1772+
```
1773+
"scripts": {
1774+
"test": "node test.js",
1775+
"start": "beefy index.js:bundle.js --live",
1776+
"pizza": "node pizza.js",
1777+
"everything": "npm run pizza && npm test && npm start"
1778+
}
1779+
```
1780+
1781+
In the terminal execute this command:
1782+
1783+
```
1784+
npm run everything
1785+
```
1786+
1787+
You just ordered pizza, ran tests, and started your development server! That’s pretty good. That easily rivals the most basic grunt.js implementations.
1788+
1789+
So, that gives you a sense of when to use npm scripts. Use npm scripts when your requirements are simple. You may find it will work for many situations.
1790+
1791+
16161792
# Introduction to grunt.js
16171793

16181794
Grunt is a tool for managing the javascript, css, and html files of your web project. Grunt is a task manager similar to Ruby's `rake`. You can run any arbitrary tasks you want, and there are a number of grunt plugins that make it easy to set up common tasks. Grunt is useful for running tests or for build steps, including turning sass, stylus, or less files into css, concatenating files, or creating .zip or .tar.gz packages of your project.
@@ -1831,42 +2007,6 @@ If you didn't get output like that, check your Gruntfile for typos. If you did g
18312007
If this seems like a lot, like it's beating up your brain, don't worry. After a few times of starting a project like this, these initial steps will get faster and easier. Heck, you might even create some kind of base project that you can build on with each new project so that you don't have to write the boilerplate every time. Or you could use a project like yeoman for its code generators. That's up to you, but when first learning this it's a reasonable idea to start from scratch and see how everything works.
18322008

18332009

1834-
# Package managers for browser code: what should I use?
1835-
1836-
When should I use npm, bower, or component for managing client-side code?
1837-
1838-
To start: always use one of them. The old days of downloading js/css libraries one by one and updating them manually are totally over, and that's exciting. Using a package manager for front-end code means we can easily download libraries, keep track of versions, and ease dependency management.
1839-
1840-
But we still have too many options for how to manage our client-side code. Beyond npm, bower, and component there are still many other options, but those three seem to be settling in as the most widely adopted.
1841-
1842-
## And all three are quite different:
1843-
1844-
### npm
1845-
npm nominally started out as a package manager for node, but now is used for any javascript, and along with a tool like browserify it's easy to use npm packages and node-style modules in the browser. It's not super useful for css libraries – but it's easy to imagine a tool (built on something like brfs) that could make bundling css npm packages super pleasant.
1846-
1847-
### bower
1848-
bower is a clear hero of client-side code: it's great for both css and javascript. It's easy to manage dependencies – even if those dependencies don't have a config file for bower. You can install a file or git repository as a dependency alongside packages in the bower registry. Bower doesn't make any assumptions about how you build or deploy code, so it is compatible with amd modules.
1849-
1850-
### component
1851-
component is a tool with a more focused and defined goal than npm and bower. It uses common js style modules. Each component may contain javascript, css, fonts, and images. Some javascript-only components can also be used in node.js. See the [Component FAQ](https://github.com/component/component/wiki/F.A.Q) for more details.
1852-
1853-
## When I use npm for browser code:
1854-
Games. There's been a lot of interesting activity in javascript game development in the node.js community using browserify. voxel.js is one of the biggest examples, with a goal of creating minecraft-like games in the browser. See the work of these people for examples:
1855-
1856-
npm/browserify will also be useful for creating applications that might share javascript code on the server and the browser. This approach also works well when the javascript requirements for the client-side are minimal, or if you prefer to write client-side code in a node style.
1857-
1858-
## When I use bower for browser code:
1859-
When the project requires a front-end framework like backbone, angular, or ember, I use bower as the package manager. It's currently the best way to package arbitrary dependencies of a javascript application. Typically using bower means that I am also using the build tool grunt.
1860-
1861-
## I don't really use component yet.
1862-
I really want to. It seems like there's some great work happening around component. I expect that there will be instances when I'll want to use some of the available components. But when that happens, I'll probably need to figure out a way to integrate component with bower or npm/browserify.
1863-
1864-
## Use all three at once!
1865-
It's possible to use packages from both bower and component while using browserify!
1866-
1867-
Check out this great guide for using components, bower packages, amd modules, and even global variables with browserify: http://dontkry.com/posts/code/browserify-and-the-universal-module-definition.html
1868-
1869-
18702010
# Part 2: In depth with javascript data types
18712011

18722012
In this section of the book we'll review strings, numbers, arrays, and objects, and focus on a problem that often comes up with each of them.
@@ -2649,6 +2789,9 @@ someString.trim();
26492789

26502790
# Changelog
26512791

2792+
## v0.8.0 - June 17, 2014
2793+
- Add Introduction to npm scripts chapter
2794+
26522795
## v0.7.0 - February 3, 2014
26532796
- Start Part 3: examples
26542797
- Add Using Backbone & jQuery with Browserify chapter

‎chapters/15-package-managers.md‎

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
# Package managers for browser code: what should I use?
2+
3+
When should I use npm, bower, or component for managing client-side code?
4+
5+
To start: always use one of them. The old days of downloading js/css libraries one by one and updating them manually are totally over, and that's exciting. Using a package manager for front-end code means we can easily download libraries, keep track of versions, and ease dependency management.
6+
7+
But we still have too many options for how to manage our client-side code. Beyond npm, bower, and component there are still many other options, but those three seem to be settling in as the most widely adopted.
8+
9+
## And all three are quite different:
10+
11+
### npm
12+
npm nominally started out as a package manager for node, but now is used for any javascript, and along with a tool like browserify it's easy to use npm packages and node-style modules in the browser. It's not super useful for css libraries – but it's easy to imagine a tool (built on something like brfs) that could make bundling css npm packages super pleasant.
13+
14+
### bower
15+
bower is a clear hero of client-side code: it's great for both css and javascript. It's easy to manage dependencies – even if those dependencies don't have a config file for bower. You can install a file or git repository as a dependency alongside packages in the bower registry. Bower doesn't make any assumptions about how you build or deploy code, so it is compatible with amd modules.
16+
17+
### component
18+
component is a tool with a more focused and defined goal than npm and bower. It uses common js style modules. Each component may contain javascript, css, fonts, and images. Some javascript-only components can also be used in node.js. See the [Component FAQ](https://github.com/component/component/wiki/F.A.Q) for more details.
19+
20+
## When I use npm for browser code:
21+
Games. There's been a lot of interesting activity in javascript game development in the node.js community using browserify. voxel.js is one of the biggest examples, with a goal of creating minecraft-like games in the browser. See the work of these people for examples:
22+
23+
npm/browserify will also be useful for creating applications that might share javascript code on the server and the browser. This approach also works well when the javascript requirements for the client-side are minimal, or if you prefer to write client-side code in a node style.
24+
25+
## When I use bower for browser code:
26+
When the project requires a front-end framework like backbone, angular, or ember, I use bower as the package manager. It's currently the best way to package arbitrary dependencies of a javascript application. Typically using bower means that I am also using the build tool grunt.
27+
28+
## I don't really use component yet.
29+
I really want to. It seems like there's some great work happening around component. I expect that there will be instances when I'll want to use some of the available components. But when that happens, I'll probably need to figure out a way to integrate component with bower or npm/browserify.
30+
31+
## Use all three at once!
32+
It's possible to use packages from both bower and component while using browserify!
33+
34+
Check out this great guide for using components, bower packages, amd modules, and even global variables with browserify: http://dontkry.com/posts/code/browserify-and-the-universal-module-definition.html

0 commit comments

Comments
 (0)