Code completed and merged. As of the next version, stripes-loader is no longer a dependency of stripes-core.

After the next stripes-core release, one minor follow-up remains to update any UI modules that import stripes-loader directly. These can be replaced with imports from stripes-config. An alias in the webpack config remains to make this version of core backwards-compatible:

If/when this alias is removed, stripes-core would require a breaking version bump. Given the simplicity of the alias in maintaining backwards-compatibility, it probably makes sense to defer removal until there is a more pressing need for breaking changes within stripes-core.

Update: As discussed with few folks recently, my next PR will fold stripes-loader logic into stripes-core as a webpack plugin.

For reference, the workflow is as follows:

From the CLI, stripes dev and stripes build continue to accept a tenant-specific strips.config.js parameter. This stripes.config.js file is loaded and the contents are passed to a new stripes config webpack plugin.

The plugin performs much of the same logic as the stripes-loader does: parses the tenant config and each ui modules' package.json to generate a new configuration suitable for runtime. This final configuration is made available to Webpack as a virtual module named stripes-config.

With the exception of an unused property, the new stripes-config matches the output generated by stripes-loader. Much like stripes-loader, stripes-config can be imported into any JavaScript file where it is needed:

For backwards compatibility, an alias for stripes-loader points to stripes-config. Some ui-modules reference stripes-loader directly and once updated, the alias can be removed.

This first round of refactoring makes no significant change to the existing interfaces for CLI input or final configuration output. What it does do is set the stage for further refactoring/organization and reuse of the plugin for other uses like a service to generate bundles (FOLIO-852).

I tried to use getOptions but, at the time, ran into some issues with it and begrudgingly used LoaderOptionsPlugin instead. Give it a shot and if it works now, I'd much rather we used it. That's actually the reason for the loader alias---previously in v1 we'd been importing '@folio/stripes-loader!' eg. a loader with no files. But I'd seen some speculation it was now mandatory to pass it a file for the options to be parsed and so had it aliased to '@folio/stripes-loader!package.json' or some similar in the process of trying to suss out what was going on there. Probably also why the config section had an includes and not an exact match. Apologies for the mess, not super-happy about the state of this.

Ultimately for SaaS deployments I expect the bundle will be generated via a Node web service where the tenant configuration interface POSTs the options (eg. what's currently in stripes.config.js for a particular tenant and would probably be in a database with the rest of their tenant-specific config) to and it runs Webpack in memory (via memory-fs) to generate the bundle. So we need it to be configurable via the Node API.

As a side note, I am seeing the stripes-loader processed twice during the build.  Once for matching stripes-loader/dist/index.js and again for stripes-loader/package.json (required in core's about.js). I'm not sure if this causes any side effects, but I'll update the test condition to avoid the extra run.

Loader options are accessible within the loader using Webpack's loader-utils library. 

To pass options using Webpack's Node API, we can dynamically apply options to the stripes-loader rule.   One approach is to remove the stripes-loader rule from the static webpack.config.base.js and inject the loader rule via stripes.js CLI:
 

Another approach would be to reshuffle our Webpack configs such that they export a function instead of an object (although that does not work with Webpack's Node API).  Alternatively, we set environment variables to be read by the configs.  Either approach would allow the configs to apply options dynamically.
 
The choice will be influenced by the overall direction we want to take in