My new favoured approach for sourcing Infusion as a front-end dependency in other projects

Harnum, Alan aharnum at ocadu.ca
Fri Sep 9 14:56:30 UTC 2016


I wanted to draw the community's attention to the approach I've taken for sourcing Infusion as a front-end dependency here in my ongoing MyL3 work: https://github.com/waharnum/myl3/blob/FLOE-471/Gruntfile.js in light of recent discussion (http://lists.idrc.ocad.ca/pipermail/fluid-work/2016-August/010072.html) – while still not especially elegant, it's a big improvement, and I'd recommend it to others with a similar need to manage Infusion as a third-party dependency for non-Node work.

This is possible because a recent change to the 'grunt build' task in the Infusion version published to NPM removed a cleanup step that removed the produced /build directory after making the ZIP file.

Following an 'npm install' in the project root, the "installFrontEnd" custom grunt task does the three things:

  *
uses the exec task to run 'npm install' in node_modules/infusion to get Infusion's own build dependencies
  *   uses the exec task to run 'grunt build' in node_modules/infusion to build the concerted + minified Infusion, plus source map
  *   uses the copy task to copy the built Infusion + other front end dependencies into the need src/lib and test/lib directories

This means I no longer have to keep Infusion checked into the repo or worry about making my own builds for the project, without having to deal with much greater complexity than a few additional Grunt tasks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20160909/26095d87/attachment.html>


More information about the fluid-work mailing list