Bower support

[kirill-konshin]

• Added bower.json file
• Added .npmignore for easier NPM publish, it will prevent unneeded files to sneak in NPM installations
• Modified package.json file (bumped version, added reference to build script, see new README.md section)
• Commented out cleanup after build procedure (files are needed for Bower and NPM)

Unfortunately, NPM publish directly from repository is not yet possible:

require('crypto-js/build/crypto-js/lib-uncompressed/aes')

is very ugly and I don't want to break backward compatibility with existing installations. So far I haven't found a way to explain NPM/Node to look for crypto-js/whatever not in root folder of package, but somewhere else.

So for now NPM publish procedure will stay the same, unless I'll find a way to leave files in sub-folders and refer to them as before. Bower requires only pre-build and can be published without extra efforts.

In order to register Bower package please do:

bower register crypto-js git://github.com/evanvosberg/crypto-js.git

So far package name crypto-js is not taken yet, so be quick :)

What could be done after this is to make the following structure (I can't make builder to produce this kind of output):

• crypto-js
• build
  • components
  • rollupds
• lib note that this folder will now contain uncompressed files
  • ...nodejs/amd stuff, point package.json's main property to index file there
• lib-compressed
  • ...nodejs/amd stuff
• src
  • ...raw files

This will require users of previous NPM package to update their references from require('crypto-js/whatever') to require('crypto-js/lib/whatever') but it seems that this is a wide-spread practice to put stuff into lib.

[kirill-konshin]

Repository begins to be a bit bloated with different kinds of builds, but it appears that for different environments different builds are required:

• build folder for non-requirejs
• lib-uncompressed or lib for requirejs
• lib for npm/node

So ideally bower install or npm install should deliver all necessary stuff

[kirill-konshin]

If you will explain how can I achieve the structure from first comment, I will update the PR.

[kirill-konshin]

I've managed to patch the builder to make stuff go to lib and lib-compressed in root. Also I've updated documentation and added some tools to verify that NPM and Bower work well (don't forget to update git links in package-tests/*.json files if PR will be merged.

Archives no longer needed since NPM package now can be published without any extra procedures except build via

npm run build
npm publish

And browser clients can download ZIP/TAR from Github.

[kirill-konshin]

As a part of the build I also recommend to bump versions in package.json and bower.json simultaneously to avoid uncertainty after publish.

[evanvosberg]

You already mentioned

Repository begins to be a bit bloated with different kinds of builds, but it appears that for different environments different builds are required:

and yes I'm not very happy with that.

I would like to keep a clear difference between repo for development and versioning and releases. I like the idea of bower, but unfortunately bower doesn't do so.

The build directory is just legacy stuff from the svn repository, just didn't want to change it being able to fetch and merge changes from the svn repo. So the repo was like a middleware to serve changes from svn via git and a build process to npm.
Since the repo is no longer in dev and some dev continues here we can change this.

The build process includes umd (CommonJS / AMD / global) definition so we can serve a single build/release bundle for all environments. I think we should get rid of all the different builds (even no compressed and uncompressed anymore).

Keep a clear difference between releases and development can be done by branches. I suggest to keep development on the develop and feature branch branches and use the master as the release branch with tagged versions. In that way we can serve a clean release without any test, build or other dev helper files.

[kirill-konshin]

True, repository should follow Gitflow principles and guidelines. According to Gitflow you do all integration and development in develop and each commit/merge to master should be treated as release. Bower uses tags to serve releases, so whenever you tag master with anything -- it means a bower release. For NPM you still have to execute a publish command.

Speaking about build, it is rudimentary, but for users it would be hard to understand which UMD modules and in which sequence should be added to the page, so build is a bit easier to understand... Although this could be solved by proper documentation.

It is normally considered as a good practice to publish not only builds, but also raw components along with something intermediate between build and components, so that end users may choose how they want to pack it, say, TypeScript raw files, AMD/CJS versions and single-file build. As an example -- Webpack suggests to use NPM versions even for frontend in order to let webpack to optimize the final build in a best possible way.

Anyway, it does not cost much for us to include different things in packages and end users would certainly appreciate some freedom of choice.

[evanvosberg]

Created a new release, had to bump the patch version, because bower doesn't load semver pre-releases. Unfortunately crypto-js package name is already taken in bower, but repo is death.

Just asked for moving the repo target bower/bower#120 (comment).

[kirill-konshin]

So I guess non-RequireJS users in order to add AES will have to add the following sequence:

1. ./core
2. ./enc-base64
3. ./md5
4. ./sha1 (for evdkdf)
5. ./hmac (for evdkdf)
6. ./evpkdf,
7. ./cipher-core"
8. ./mode-ecb.js
9. ./aes

Do you really want to get rid of bre-built files? :)

[evanvosberg]

There is one file crypto-js.js in, with the whole library ;)

But yes it's missing in the README, should add this.

[kirill-konshin]

Aw, OK :) it's 32KB, so not a big deal at all... Btw, this file could also have minified version nearby, and normal practice is to put both of them in dist folder.

Btw, Contribution section in README.md should actually be in CONTRIBUTING.md which is automatically picked by Github.

[evanvosberg]

CONTRIBUTING.md nice didn't know this.

Currently I'm targeting the bower support, but I want to automate the release process a bit more in future.

As I already mentioned I like the idea of bower to provide packages independent from runtime env (not like npm) and I also use it, but it's actually not a really proper solution to use development repositories as package manager distribution network. Usually a development repo can be something totally different to a release, due to build processes, compilers, different platform releases and so on ...

For that reason I decide to provide clean releases on master with tagged versions and everything else can be found in the repo under dev. I never use minified libraries in my projects due to debugging while dev and at the end I just minify the whole project before pushing it on a live platform, so it's not necessary to have minified files.

Just remember git "GitHub" is a versioning tool for development and contribution not a CDN or release platform ;)

[kirill-konshin]

Well it seems to be a regular practice to keep all the stuff in single repo... It's a lot more convenient rather then to partially copy-paste files from other branches/repos before publishing.

Speaking about minified versions -- source maps solve all debugging issues and minified version itself is sometimes needed when project does not use any specific build tools. But it is totally optional.

With Github "Releases" tab it can be used as CDN or release platform :)

[kirill-konshin]

Plus single-repo approach is the least confusing for contributors:

npm run build

Build can also include tests, JSHint/JSLint and all other code quality checks. I've also seen how people fail the build when code coverage condition is not met.

[kirill-konshin]

I have rebased the PR, now it contains only documentation and package.json fixes.

[kirill-konshin]

I wonder how come I measured that build crypto-js.js is 32K, it's in fact 191K, which is a huge file... but anyway, if needed, the one can switch to separate files as I mentioned earlier.