One, the benefits of make
First explain why you want to use made.
Currently, Web site projects (especially Node.js projects) have three of build scenarios.
Scenario One: Node.js-based dedicated build tools (grunt, Gulp, brunch, broccoli, Mimosa)
Scenario Two: NPM Run command (Tutorials 1, 2, 3)
Scenario Three: Make command
I think that make is the preferred option for large projects. NPM run can be considered a simplified form of make, only for simple projects, and tools like grunt and gulp have many problems. The
(1) plug-in problem
Grunt and gulp operations are completed by the plug-in. Even if the file is renamed such a simple task, to write Plug-ins, quite troublesome. Make is a direct call to the command line, and there is no need to worry about not finding the plugin. The version of the
(2) Compatibility issue
plug-in must match the version of Grunt and gulp, and must also match the corresponding command-line program. For example, the Grunt-contrib-jshint plugin is now a 0.11.0 version, corresponding to the grunt 0.4.5 version and Jshint 2.6.0 version. If grunt and Jshint are upgraded and the plugin is not upgraded, compatibility issues may occur. Make is a direct call to Jshint, and this problem does not exist.
(3) syntax problems
Grunt and Gulp have their own syntax, it is not easy to learn, especially grunt, grammar is very wordy, it is difficult to see the intention of the code. Of course, make is also not easy to learn, but it has reusability, learned to use in other occasions. The
(4) Feature problem
make has been in use for decades, and many of the world's largest projects have been built with it, proven to be very reliable, all kinds of situations have been resolved, and the experience and information accumulated by previous generations have been very rich. By contrast, grunt and gulp have a long history and a limited range of uses, and there are no tasks that they can do and make.
For the above reasons, I'm bullish on make.
Two, common build tasks
are some of the common web site building tasks below.
Check Syntax
compile template
transcoding
merging
Compress
test
Delete
These tasks use tools such as Jshint, handlebars, Coffeescript, UGLIFYJS, Mocha, and so on. The corresponding Package.json file is as follows.
"devdependencies": {
"Coffee-script" : "~1.9.1",
"handlebars": "~3.0.0",
"Jshint": "^2.6.3",
"Mocha": "~2.2.1",
"Uglify-js": "~2.4.17"
}
Let's see how the Make command completes these build tasks.
Iii. General configuration of Makefile
Before you start building, write makefile files. It is the configuration file for the make command. The build rules for all tasks are written in this file (see the Make command Tutorial).
First, write a two-line generic configuration.
Path: = node_modules/.bin:$ (path)
SHELL: =/bin/bash
The path and shell of the above code are bash variables. They are assigned a new value.
The path variable is nodemodules/.bin, giving precedence to looking for commands in the directory. This is because the node module (the current project) will set a symbolic link in the Nodemodules/.bin directory. After the path variable points to this directory, invoking the various commands does not have to write the path. For example, call Jshint, you do not have to write ~/node_modules/.bin/jshint, only write Jshint on the line.
The shell variable specifies that the build environment uses bash.
Check grammar errors
The first task is to check the source code for any grammatical errors.
Js_files = $ (Shell find./lib-name ' *.js ')
Lint: $ (js_files)
Jshint $?
In the code above, the shell function calls the Find command, finds all the JS files in the Lib directory, and saves them in the variable js_files. Then, you can check the files with Jshint.
Call the following command when used.
$ make lint
Five, template compilation
The second task is to compile the template. Assume that templates are in the Templates directory and need to be compiled into templates.js files in the build directory.
Build/templates.js:templates/*.handlebars
Mkdir-p $ (dir $@)
Handlebars Templates/*.handlebars > $@
Template:build/templates.js
The code above looks at whether the build directory exists and creates a new one if it does not exist. The Dir function is used to remove the path name (build) of the building target, and the built-in variable $@ represents the build target (build/templates.js).
Call the following command when used.
$ make Template
Six, coffee script transcoding
The third task is to convert the Cofferscript script into a JavaScript script.
Source_files: = $ (wildcard lib/*.coffee)
Build_files: = $ (source_files:lib/%.coffee=build/%.js)
Build/%.js:lib/%.coffee
Coffee-co $ (dir $@) $<
Coffee: $ (build_files)
In the code above, first get all the coffee script files, stored in the variable sourcefiles, the function wildcard to extend the wildcard character. Then, replace the coffee file name in the variable sourcefiles with the JS filename, which is lib/x.coffee replaced with Build/x.js.
Call the following command when used.
$ Make Coffee
vii. Consolidation of documents
Use the cat command to merge multiple files.
Js_files: = $ (wildcard build/*.js)
OUTPUT: = Build/bundle.js
Concat: $ (js_files)
Cat $^ > $ (OUTPUT)
Call the following command when used.
$ make Concat
Eight, compressed JavaScript script
Compresses all JavaScript scripts into app.js in the build directory.
App_bundle: = Build/app.js
$ (App_bundle): $ (build_files) $ (TEMPLATE_JS)
UGLIFYJS-CMO $@ $^
Min: $ (app_bundle)
Call the following command when used.
$ make min
There is another way of writing, you can specify a separate compression tool.
Uglify? = uglify
$ (App_bundle): $ (build_files) $ (TEMPLATE_JS)
$ (uglify)-CMO $@ $^
The above code puts the compression tool uglify in the variable uglify. Notice that the variable's assignment is? =, indicating that the variable can be overridden by a command-line argument.
Write this when called.
$ make uglify=node_modules/.bin/jsmin min
The above code, the Jsmin command to the variable uglify, compression will use the Jsmin command.
ix. Deletion of temporary documents
Delete all temporary files before the build is finished.
Clean
RM-RF Build
Call the following command when used.
$ make clean
10, testing
Assume that the test tool is mocha and that all test cases are placed under the test directory.
Test: $ (app_bundle) $ (TEST_JS)
Mocha
When both the script and the test case are present, the code above executes mocha.
Call the following command when used.
$ make Test
11. Multi-Task Execution
The build process needs to perform multiple tasks at once, and you can specify a multiple-task target.
Build:template concat min Clean
The code above specifies the build as four tasks for performing template compilation, file merging, script compression, and deletion of temporary files.
Call the following command when used.
$ make Build
If the line rule is at the top of the makefile, the target name can be omitted when executed.
$ make
Normally, make performs one task at a time. If the tasks are independent and have no dependencies on each other, you can use parameter-j to specify that multiple tasks are executed concurrently.
$ make-j Build
12, the declaration of false Documents
Finally, to prevent the target name from conflicting with an existing file, explicitly declare which target is a pseudo file.
. Phony:lint Template coffee concat min test clean build
13, makefile file Example
Here are two simple makefile files to complement the other build tasks of the Make command.
example One.
Project = "My Fancy node.js project"
All:install test Server
Test:; @echo "Testing ${project} ..."; \
Export node_path=.; \
./node_modules/mocha/bin/mocha;
Install:; @echo "Installing ${project} ..."; \
NPM Install
Update:; @echo "Updating ${project} ..."; \
git pull--rebase; \
NPM Install
Clean:;
RM-RF Node_modules
. Phony:test Server Install clean update
instance two.
All:build-js Build-css
BUILD-JS:
Browserify-t Brfs src/app.js > Site/app.js
BUILD-CSS:
Stylus Src/style.styl > Site/style.css
. Phony Build-js Build-css