Package.js modern JavaScript project make tool_javascript skills

Package.js project address: http://code.google.com/p/package-js/

Package .js is a very convenient JavaScript package dependency management and Make tool. Its design goal is to make browser-side JavaScript Component/App development more modular. If you are just developing a small website and only mix a few lines of JS code in HTML to improve the user experience, then Package.js may not be suitable for you. If you are developing a medium to large WebApp, there are dozens or even hundreds or thousands of JS files, CSS files, and HTML template files. If you are troubled by managing the dependencies and loading between these JS modules, publish to In the production environment, merging and packaging JS files makes you dizzy when writing the Makefile. Then, Package.js, this is what you want! Come and learn about and use Package.js!

Package.js mainly consists of two parts

The JS library API that runs in the browser and is used to define and import modules
runs in the node.js environment to integrate all JS The make tool for merging packages and their dependent CSS and HTML files

Package.js browser-side API refers to the CommonJS/AMD specification and is compatible with this The simplest form of the specification, and extends some syntax based on this to facilitate the development of JavaScript UI components including CSS and HTML templates.

Let’s take a look directly at the directory structure of the project developed using Package.js, it is simple and clear:

Copy code The code is as follows:

Test
├── dom
│ └── Style.js #Module file with namespace Test.dom.Style
├── init.js #Root namespace initialization file
├── _nsconf_.js #Package.js will read the configuration file
├── ui
│ ├── Button
│ │ ├── img
│ │ │ └── bg.png
│ │ ├── init.js #Test.ui.Button namespace module file
│ │ ├── style .css #CSS file of UI component
│ │ └── tpl.html #HTML template file of UI component
│ └── Form
│ ├── init.js
│ ├─ ─ style.css
│ └── tpl.html
├── util
│ └── Cookie.js #JS package with namespace Test.util.Cookie
└── _xproxy_ .html -> ../Package/_xproxy_.html #This file is a Soft Link pointing to Package/_xproxy_.html in the Package.js source code, which is used to load HTML template files across domains

Package.js, module definition syntax -
Root/ui/Button/init.js code:

Copy code The code is as follows:

Package.define("Root.ui.Button",["Root.ui.Pane","Root.util.Tpl","Root.util.Event"],
function (Pane,Tpl,Event) {
//Pane is Root.ui.Pane
//Tpl corresponds to Root.util.Tpl
//and so on
//. ....
});

Different from the AMD specification of CommonJS, in the syntax of Package.js, a JS module can not only rely on other JS packages, but also rely on CSS and HTML template files, and other JSON data files, and at runtime, obtain the contents of other dependent files. The definition syntax is as follows:

Copy code The code is as follows:

Package.define("NS.ui .Button",["MT.ui.Component"],
{
tpl:"tpl.html",
_style:"style.css"
},function (Component) {
//Access tpl.html content through this.assets.tpl
var bgImgUrl=this.path "img/bg.png",tpl=this.assets.tpl;
function Button(opt) {
//You can also access assets through the _pkgMeta_ attribute of the current Package object
this.tpl=String2Dom(opt.tpl || Button._pkgMeta_.assets.tpl);
}
return Button;
})

In the browser, you can use the following method to import a JS module.
During the import process, Package.js automatically does the logistical work for you: 1 , load the dependent modules of this module. 2. Load dependent HTML and CSS files.

Copy code The code is as follows:

Package.imports(["Root.ui.Button" ],function (Button) {
var btn=new Button();
btn.renderTo(document.body);
});

During development, for modularization, you need to divide JS into small module files, but when publishing to the production environment, for the sake of loading speed, you need to merge these JS files into a single JS file and Compression, similarly, CSS files should be merged together.

Copy code The code is as follows:

//Your packaging configuration file
// build-config.json file content
{
"staticUrls": {"defaults":"http://statics.iwt.macrotarget.com/jslibs/"},
"nsconfs":[" http://www.cnblogs.com/statics/jslibs/XLib/_nsconf_.js"],
"includes":["XLib.apps.MainApp","XLib.ui.*"],
"compress":true //Use UglifyJS and UglifyCSS for compression
}

With the help of Package.js, to complete this function, you only need to write three or four lines of JSON configuration code and execute a command, Everything is OK.

Copy code The code is as follows:

#Execute command
build.js build-config .json js all.min.js
build.js build-config.json css all.min.css
#My waist is no longer sore and my legs are no longer painful!

Quote

PS: build.js also does a little thing for you: convert relative paths such as background:url() in CSS files into absolute URLs. When you are developing, url() in CSS always only needs to write a relative path. When deployed to the production environment, the CSS merged by build.js will automatically convert it into an absolute URL. Even if you use the IE6 Png AlphaImageLoader filter and wui4ie6 loader, you can still write relative paths in src= during development. In development mode, Package.js will also automatically generate CSS Rules using absolute URLs. The src of AlphaImageLoader will also be converted when packaging. There is no need to write absolute URLs in CSS

What are the advantages of Package.js compared to other module loaders and AMD implementations (RequireJS, SeaJS...) Or shortcomings?

Package.js is developed for Web App Framework. The definition syntax and file directory structure are strict (or slightly complicated). It only uses the simplest define syntax in the AMD specification
Package.js The JS module's dependence on CSS and HTML files is distinguished from its dependence on other JS modules in the way of define writing, and the processing of CSS, HTML, and JSON packaging is also included in build.js
(TOT) includes Special care for IE6 CSS (no way, our own project needs it)
Add PackageMeta, a JS module can know its own URL at runtime
... If it is a disadvantage: not completely consistent with the CommonJS AMD specification Compatible with
Build supports three export modes: includes, deps, all
More convenient in development mode: use _xproxy_.html for cross-domain loading, no proxy required. Using _nsconf_.js, there is no need to configure paths.

After listening to these simple introductions, you may be eager to try Package.js. Before using it, you can refer to the details of
Package.js Documentation:http://package-js.googlecode.com/hg/docs/Package.html.

Okay! Stop using backward methods to develop JavaScript apps, stop being Out Man, and use Package.js as soon as possible ^O^