Feedback requested: improving Infusion's NPM package for end users in the short term

[Harnum, Alan]

There was a question in the channel from Antranig about going into more detail about what I think the end-user workflow would look like when building a project. Essentially I'd anticipate:

  1.  An user (a developer setting up a local environment, or someone deploying a site using browser-based Infusion)  runs 'npm install' to install Infusion as part of a project's dependencies.
  2.  They then run a grunt task to copy the needed Infusion files into a project structure that can be run locally or served by Apache/nginx or another static site server

You can see this workflow in action in a few of my repos:

  1.  https://github.com/waharnum/chartAuthoring/blob/GPII-1584/Gruntfile.js (copying D3 and Flocking as front-end dependencies after installing them with NPM)
  2.  https://github.com/waharnum/myl3/blob/FLOE-471/Gruntfile.js (copying PouchDB as a front-end dependency after installing with NPM)

All three of those packages are notable for providing a number of artifacts after installation from NPM that are suitable for this kind of approach.

From: Justin Obara <obara.justin at gmail.com<mailto:obara.justin at gmail.com>>
Date: Thursday, August 18, 2016 at 4:15 PM
To: Fluid Work <fluid-work at fluidproject.org<mailto:fluid-work at fluidproject.org>>, Alan Harnum <aharnum at ocadu.ca<mailto:aharnum at ocadu.ca>>
Subject: Re: Feedback requested: improving Infusion's NPM package for end users in the short term

To add to Alan’s points, I’m linking in FLUID-5579 which was an issue filed a couple years ago covering a similar concern.

https://issues.fluidproject.org/browse/FLUID-5579

Thanks
Justin



On August 18, 2016 at 10:54:12 AM, Harnum, Alan (aharnum at ocadu.ca<mailto:aharnum at ocadu.ca>) wrote:

The essential issue is that as currently stands Infusion's build process and publication to NPM makes it less than friendly for use in automating build processes for front-end (in-browser) use.

- PR comment that started this thread of conversation: https://github.com/fluid-project/myl3/pull/1#discussion_r75114980
- Relevant IRC chat start: https://botbot.me/freenode/fluid-work/2016-08-17/?msg=71467811&page=1

The long-term remedy for this may be making Infusion work well with the current generation of front-end build tools like Browserify or web pack, but in the more immediate term, it was proposed to estimate the effort to produce a distribution structure like the following gist as part of the published NPM package: https://gist.github.com/waharnum/4d1f3845ce6b8dc7ed6d4c9dcd23f69e.

Many NPM libraries that can be used in-browser include a `/dist` directory or similar that contains a selection of suitable (concatenated / minified / etc) front-end artifacts. The proposed structure above tries to more easily accommodate two basic use cases:

  *   applications with in-browser Infusion as a dependency that only wish to use the framework pieces (both with and without the jQuery dependency)
  *   applications with in-browser Infusion as a dependency that wish to additionally use various interface components that include JS along with HTML, images and CSS assets

Per previous discussion in March (http://lists.idrc.ocad.ca/pipermail/fluid-work/2016-March/009894.html), my various browser-based (non-node) projects with Infusion + 3rd party libraries as dependencies uses NPM + grunt only to manage the "install" process; Infusion itself is, for the reasons stated in the PR comment above, resistant to this approach, and continues to be checked in directly as a dependency. We'd like to address this, and it seems better to spend a little time doing so at the root of the issue than for me to do so via grunt in each of my projects.

Comments are invited about the approach/goal described above – there is some discussion about trying to accomplish this for the Infusion 2.0 release. Justin O & I discussed & think it might be possible to achieve it relatively quickly using existing build tools.

ALAN HARNUM
SENIOR INCLUSIVE DEVELOPER
INCLUSIVE DESIGN RESEARCH CENTRE, OCAD UNIVERSITY

E aharnum at ocadu.ca<mailto://aharnum@ocadu.ca>

OCAD UNIVERSITY
100 McCaul Street, Toronto, Canada, M5T 1W1
www.ocadu.ca<http://ocadu.ca/>

_______________________________________________________
fluid-work mailing list - fluid-work at lists.idrc.ocad.ca<mailto:fluid-work at lists.idrc.ocad.ca>
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20160822/82f39ac7/attachment.htm>