aharnum at ocadu.ca
Tue Mar 1 18:33:24 UTC 2016
The Chart Authoring Tool (https://github.com/fluid-project/chartAuthoring) is built with Infusion, the D3 data visualization library, and the Flocking audio synthesis framework (created by the Fluid community's own Colin Clark).
At the moment the non-Infusion dependencies are directly included as files in the project repository. This is simple, but bad in various other ways in terms of keeping things up to date, keeping the repo clean, etc.
There has been an outstanding issue since last August to improve this situation (https://issues.fluidproject.org/browse/FLOE-405?jql=text%20~%20%22bower%22<https://issues.fluidproject.org/browse/FLOE-405?jql=text%20~%20"bower">).
Infusion itself is moving in this direction as NPM becomes a more viable for front-end management, as evidenced by this issue: https://issues.fluidproject.org/browse/FLUID-5745?jql=text%20~%20%22bower%22<https://issues.fluidproject.org/browse/FLUID-5745?jql=text%20~%20"bower">
My Immediate Goal / Challenge
I'm starting work on front-end Infusion-based components for the GPII Quality Infrastructure where I would like to be able to reuse some code from the Chart Authoring repo itself, so rather than replicate the problem again I’d like to have an approach that does the following:
- works with the existing toolstack for builds (npm + grunt) without other tool dependencies such as browserify, webpack, etc
- produces a suitable static “package" for serving publicly, as is used currently by http://build.fluidproject.org/
- has minimal development overhead but improves the current situation
- can be replaced easily enough in the future when we align on a better means of managing front-end dependencies
What I Propose
Examples here are in the context of the Chart Authoring Tool project in my fork at https://github.com/waharnum/chartAuthoring/blob/FLOE-405/ but I’d like the general shape of this to be applicable to other cases:
- front-end dependencies should be managed using NPM’s package.json format and installed via a standard ‘npm install’ (https://github.com/waharnum/chartAuthoring/blob/FLOE-405/package.json)
- one or more grunt tasks should then be used to copy these dependencies into an appropriate structure for use by the front end project (https://github.com/waharnum/chartAuthoring/blob/FLOE-405/Gruntfile.js)
- a .gitignore definition should be used to make sure this external dependency directory is not versioned (https://github.com/waharnum/chartAuthoring/blob/FLOE-405/.gitignore)
We talked about this approach briefly at the Floe planning meeting yesterday and people seemed receptive, but the broader community should weigh in and give their opinion.
1) Do we feel OK with this approach to front-end dependency management in the short term?
2) If we don’t feel OK about it, what should we do instead?
SENIOR INCLUSIVE DEVELOPER
INCLUSIVE DESIGN RESEARCH CENTRE, OCAD UNIVERSITY
E aharnum at ocadu.ca<mailto://email@example.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work