Proposal: better intermediary means of managing external front-end Javascript dependencies in Infusion-based projects using nom + grunt

[Tirloni, Giovanni]

Jumping on this thread to share this npm-related news:

   https://medium.com/@azerbike/i-ve-just-liberated-my-modules-9045c06be67c#.7tr96nssz

This developer unpublished 250 packages he owned as a statement against npm, Inc. I won't comment on the efficacy of that but I found it worrisome that packages are not published permanently, the ownership can be transferred and old versions can even be republished.

There is a lengthy discussion here: https://news.ycombinator.com/item?id=11340510

On 03/01/2016 03:33 PM, Harnum, Alan wrote:
> *Background*
> *
> *
> 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 ~ "bower">).
>
> Originally the thought was to use Bower, but Bower seems to be facing some challenges as a project (https://www.reddit.com/r/javascript/comments/3th4v6/bower_vs_npm_3_frontend_package_management/) and the general direction of many other projects seems to be towards using straight npm (sometimes with a tool like browserify) to manage front-end dependencies.
>
> 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 ~ "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)
>
> Basically, a front-end project will pull in its dependencies via NPM and then distribute them as needed via grunt to create the necessary “product"; the specifics of this will depend on the particular project. We already use both npm and grunt in other contexts, they’re familiar to us, and they avoid the need (which we have, but longer term) to adopt a specific additional piece of tooling for front-end dependency management, which is a space that seems in heavy churn right now in the Javascript community.
>
> 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.
>
> *Questions*
> *
> *
> 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?
>
> *ALAN HARNUM*
> SENIOR INCLUSIVE DEVELOPER
> INCLUSIVE DESIGN RESEARCH CENTRE, OCAD UNIVERSITY
>
> *E *aharnum at ocadu.ca <mailto://aharnum@ocadu.ca>
>