Potential options for addressing FLUID-6359: Make the dist directory self contained
Moss, Gregor
gmoss at ocadu.ca
Wed Sep 18 01:02:12 UTC 2019
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/248f5bda/attachment.htm>
More information about the fluid-work
mailing list