Potential options for addressing FLUID-6359: Make the dist directory self contained

Wed Sep 18 13:23:19 UTC 2019

Hi Gregor,

Thanks for testing things out. Regarding your question about other packages, below I’ve collected a handful of projects. Please suggest others as well.

Angular <https://unpkg.com/browse/angular@1.7.8/>
No dist
Backbone <https://unpkg.com/browse/backbone@1.4.0/>
No dist
Bootstrap <https://unpkg.com/browse/bootstrap@4.3.1/>
dist directory separated into css and js directories.
D3 <https://unpkg.com/browse/d3@5.12.0/>
dist directory, only contains js builds
Dojo <https://unpkg.com/browse/dojo@1.15.0/>
No dist
Ember <https://unpkg.com/browse/ember@1.0.3/>
No dist
Foundation <https://unpkg.com/browse/foundation@4.2.1-1/>
No dist
jQuery <https://unpkg.com/browse/jquery@3.4.1/>
dist directory, only contains js builds
KendoUI <https://unpkg.com/browse/kendo-ui-core@2019.3.917/>
No dist
Leaflet <https://unpkg.com/browse/leaflet@1.5.1/>
dist directory, top level css and js builds, subdirectory for images
React <https://unpkg.com/browse/react@16.9.0/>
No dist
Semantic-UI <https://unpkg.com/browse/semantic-ui@2.4.2/>
dist directory, top level css and js builds, subdirectories for components and themes
Skeleton <https://unpkg.com/browse/skeleton-css-webpack@2.0.4/>
No dist
SproutCore <https://unpkg.com/browse/sproutcore@1.11.2-25/>
No dist
Svelte <https://unpkg.com/browse/svelte@3.12.1/>
No dist
TensorFlow <https://unpkg.com/browse/@tensorflow/tfjs-core@1.2.9/>
dist directory, top level builds, subdirectories for others
UIkit <https://unpkg.com/browse/uikit@3.2.0/>
dist directory separated into css and js directories.
Vuejs <https://unpkg.com/browse/vue@2.6.10/>
dist directory, only contains js builds

As can be seen from above there are a few different approaches:
No dist
dist separated into directories
dist with builds at the top level and subdirectories

In some of the cases above, the structure of the node module is such that a dist isn’t needed or a simplified one is enough. Either the code base is small enough, or only the packaged contents are published. 

The suggestions I made are most like "dist directory, top level builds, subdirectories for others”. Other than possibly TensorFlow, it doesn’t appear that the repos are replicating the src directory structure in dist.

Thanks
Justin

> On Sep 17, 2019, at 9:02 PM, Moss, Gregor <gmoss at ocadu.ca> wrote:
> 
> Hi Justin,
>  
> I’ve just tried out both releases in the Storytelling Tool, and I didn’t notice any issues. That said, my use of the dist directory is limited to pulling infusion-all.js and the following UIO CSS files:
> Enactors.css
> PrefsEditor.css
> SeparatedPanelPrefsEditor.css
>  
> With that in mind, the impact for my usage is minimal. The shorter paths in the collectedAssets release were nicer to look at, but that’s about it.
>  
> I’m just marginally partial to Option 1 for a few reasons you’ve already mentioned. I appreciate that the files are in the same location within the dist directory that they would be in the source, so if I find a bug or would otherwise like to make a change, I don’t have to go hunting.
>  
> Are there any examples of packages that have a dist directory with assets like CSS and images in them? I wasn’t able to find packages that weren’t related to IDRC or RTF. I’m curious to know if any such packages are simplifying their dist directories in favour of centralizing their assets versus mirroring the source structure.
>  
> Cheers,
> Gregor
>  
> From: fluid-work <fluid-work-bounces at lists.idrc.ocad.ca> On Behalf Of Justin Obara
> Sent: September 6, 2019 09:44
> To: Fluid Work <fluid-work at fluidproject.org>
> Subject: Potential options for addressing FLUID-6359: Make the dist directory self contained
>  
> We’ve been moving towards recommending NPM for pulling Infusion into web based projects. It simplifies the process of version tracking, updating, sourcing the latest or specific dev releases, and includes many common custom builds. However, the dist directory has not contained all of the resources required for use in web applications. Specifically things like HTML templates, JSON message bundles, and some CSS were not included in the dist/assets/ directory and needed to be referenced directly from src. 
>  
> Earlier this year I filed FLUID-6359 <https://issues.fluidproject.org/browse/FLUID-6359> and have been tracking various options for addressing the issue of missing resources in dist/assets/. Today I’ve published a couple of dev releases from branches that take two approaches to solve the issue. I hope that you’ll take some time to test them out in your projects, let me know if there is anything missing or other bugs, and provide feedback on the approaches. For reference the current structure of the dist/ directory can be seen in the latest dev release 3.0.0-dev.20190905T163833Z.b024bff87 <https://unpkg.com/browse/infusion@3.0.0-dev.20190905T163833Z.b024bff87/dist/>.
>  
>  
> Options 1: Copy resources to dist/assets/ retaining the tree structure from src/
>  
> In Option 1, we copy over required resources from the src/ directory to dist/assets/; including the CSS, Images, Templates, Messages, and some JS files not included in any of the compiled builds. This option retains the tree structure from source. An example of the structure can be seen in the 3.0.0-dev.20190906T123329Z.e5ad6fbc6.FLUID-6359-src <https://unpkg.com/browse/infusion@3.0.0-dev.20190906T123329Z.e5ad6fbc6.FLUID-6359-src/dist/> dev release.
>  
> Benefits:
> Easier to find items if you already knew where they were in src/
> Retains structure so you know which files are associated
> Avoids potential collisions of files with the same name across components (currently do not have any name collisions)
> Because the structure is the same, there are no issues with relative URL paths in CSS files
>  
> Disadvantages:
> Harder to see all of the files at a glance
> Harder to find individual files, especially if you don’t already know the structure
> Harder to write URL references of copy statements because of the added directory nesting
>  
>  
> Options 2: Copy resources to dist/assets/ grouped by type
>  
> In Option 2, we copy over required resources from the src/ directory to dist/assets/ but regroup into directories based on their type. For example all CSS files are in dist/assets/css/. However, 3rd party resources will retain their tree structure and be put under dist/assets/lib/. We need to rewrite relative paths to lib resources in CSS, but the other resource were already, by convention, sourced from adjacent directories. An example of the structure can be seen in the 3.0.0-dev.20190906T123957Z.756c03fe5.FLUID-6359-collectedAssets <https://unpkg.com/browse/infusion@3.0.0-dev.20190906T123957Z.756c03fe5.FLUID-6359-collectedAssets/dist/> dev release.
>  
> Benefits:
> Easier to find items
> Easier for writing URLs and/or copy routines
>  
> Disadvantages:
> Potential collisions of files with the same name across components (currently do not have any name collisions)
> Won’t necessarily know which files are related to which components; particularly the case for image files.
> Need to rewrite relative URLs to the lib/ directory in CSS files.
>  
> Thanks
> Justin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20190918/9931d1de/attachment.htm>