Web Resource Packaging approaches

Compare all managers how they allow to create packages. From that point, that you what to build your project in package manner.

package_mgmt_header

Packaging is one of Current Common.JS efforts/standards, which should be implemented to be called “Common.JS oriented”.

Standard: http://wiki.commonjs.org/wiki/Packages/1.0#Package_Descriptor_File

From here about modules: To be usable in secured module loaders, a module must conform to additional constraints:

  1. A module must not write to any free variables or their transitive members.
  2. A module must not refer to any free variables apart from primordials (“Object”, “Array”, etc. as defined by ECMAScript), “require”, “environment”, and “exports”.
  3. A module must not tamper with (assign to, assign to members of, delete, or otherwise mutate) the transitive primordials.

Node.JS:NPM package approach. Res1 Res2 Res3

npm package format provides value in itself in both portability and ease of installation. For example, you can install packages directly from Github, and even specify a tag, sha, or branch if you want.

A Node/npm module is just an ordinary JavaScript file with the addition that it must follow the CommonJS module spec.

Cons:

  • It requires to publish module/package to NPM registry. And ONLY !!! after that u can “npm install mymodule”.
  • It requires to create NPM user “npm adduser”. Then u can “npm publish folder” or “npm publish .”.
  • You create new version of module, and change package.json with new version, and u will be able to “npm publish” again.
  • Even after “npm unpublish test-splitter@1.0.0” and “npm unpublish test-splitter@1.0.1” I COULDN’T publish the same version again. I should publish totally new version, based on NPM registry history.
  • Even if DMG and PLREG create dedicated NPM registry and after that I will “npm install dmg” or add dmg as dependency in package.json IT WILL INSTALL DMG and PLREG into node_modules folder
  • It requires that all plugin hosted on dedicated git repo, and contain only module/plugin content. It doesn’t work with partial clone via appending folder as in SVN.

Pros:

  • we can easily manage different modules/plugins with multiple versions

Node.JS:Bower packaging:

  • Installs all code into bower_components, but folder can be configured.
  • Installs from bitbucket repo (via https directly from master) – simple folder. Installing via git:// with some errors. Installing from direct URL.
  • Not required to publish to bower global registry. No need, but can be registration of package on bower registry.
  • If no bower.json it creates .bower.json with some defaults data, and put it into /bower_components/<my-package>/.bower.json. Not sure if this file we need in fact.
  • Bower is not opinionated about the structure of the code in the files or how it is loaded. This means that Bower is not built with opinions on scripting loader or modular loading.

Volo approach

  • Doesn’t install by url “volo install”.

Component approach

  • Has support of github and bitbucket via registering user and password on file system, which is not very secured
  • Issues on installation
  • Requires very strict component.js with information about javascript, styles, templates – looks like package of Web project.

Nested git repos approach.

Not recommended. And not possible.

Git submodules.

Possible, but requires dedicated git repo FOR ONLY plugins folders (config.json, i18n.json, etc)

Maven approach

Possible. Not yet tested.

 So the winner for my project is Bower.

Resources:

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