browser client build/install process improvements

Bug #1350350 reported by Bill Erickson
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Undecided
Unassigned

Bug Description

Packaging the browser client currently looks something like this:
* dependency retrieval (angular, etc.)
* running unit tests (optional)
* minifying JS and CSS files
* moving dependencies and minified files into a 'build' directory.

For reference, dependencies currently include:
* Bootstrap CSS
* angular
* angular-route
* angular-mocks (unit tests only)
* angular-bootstrap
* angular-hotkeys

The full packaging process looks like this:

http://evergreen-ils.org/~erickson/browser-client-deps.html

I've added most of that to the build/tools/make_release script in the browser client branch, activated with a new "-c" option. With that, the process of creating Evergreen releases w/ the browser client included looks more like:

* Install modern version of node.js (see again http://evergreen-ils.org/~erickson/browser-client-deps.html)
% sudo npm update
% sudo npm install -g grunt-cli
% sudo npm install -g bower
% build/tools/make_release -c <other stuff>

Like other release-building dependencies, the node/sudo stuff only happens once.

make_release will create and populate the build directory w/ files, which is where the browser client expects to find all of the dependencies and, if enabled, the combined core dependencies minified JS file.

All of the above has no effect on the dependencies needed to *run* Evergreen. The final product is simply more JS files executed by the browser.

---------

For make_release, this process does not seem terribly onerous. Particularly since in time it will replace all of the XUL dependency fetching and packaging and the prereqs required for that.

What about developers, though, building code from Git checkouts?

If you are working on the browser client, then the above is needed for executing unit tests, so going through these steps is inevitable. What if you are not working on the browser client and want to install/run Evergreen to test your non-browser code? Do we make node/grunt/bower requirements for building Evergreen and put the build steps directly into the Makefile (instead of make_release)? This would be my preference over, say, pushing pinned versions of dependencies to a community-hosted location to be fetched w/ a curl script, which is one more thing to maintain (and does what bower already does for us), but I'd like to get some feedback on that before adding these dependencies.

If we go the all-in route, the dependencies (node/grunt-cli/bower) would be added to Makefile.install and the actual 'grunt build' / 'grunt test', etc invocations would be added to Open-ILS/web/Makefile.in

Revision history for this message
Bill Erickson (berick) wrote :

In the spirit of improving the browser client installation, I've pushed a branch that adds the new jquery dependency to the dependency builder/installer:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1350350-browser-client-jquery-dep

Adding 'pullrequest' for this ^--, but we either want to remove the pullreq after this is merged, since it does not address the Makefile aspects of this ticket.

tags: added: pullrequest
Changed in evergreen:
milestone: none → 2.8.0
milestone: 2.8.0 → 2.8.1
Revision history for this message
Mike Rylander (mrylander) wrote :

I have approximately the same in 158a73c51cc321362427c0f19d5fc813ecb7c6a5 ... can we wait for the next batch of changes from the WIP web client code to go in, instead, to avoid rebasing conflicts? What's in 2.8 currently really isn't safe for use in the real world anyway.

Counter arguments welcome. :)

Revision history for this message
Bill Erickson (berick) wrote :

Oops, I meant to mark that as 2.next. And no objections to waiting for the next batch. I'll remove pullreq. Thanks, Mike.

Changed in evergreen:
milestone: 2.8.1 → none
tags: removed: pullrequest
Revision history for this message
Dan Scott (denials) wrote :

Closing as resolved, jquery has been in the web based staff client for quite a while now...

Changed in evergreen:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.