Closing now, with gratitude to @Adam Dickmeiss.

I verified this. It works.

This is beyond insane.

(But very good news.)

And to make things even weirder, Adam now claims that this PR https://github.com/folio-org/ui-plugin-eusage-reports/pull/42 which downgrades chart.js from ^3.1.0 to ^2.6.0 makes the whole problem go away. If it really does fix the problem, then it's the weirdest damn thing I've ever seen. And that's saying a lot.

So much has happened! I will not try to recount anything like a blow-by-blow, but a basic summary:

• ERM-1887 meant that the Agreements app was fundamentally unable to display any agreement that has any usage data! It was caused by a bizarrely basic problem – an empty index.js – which has now been fixed in master. The real question is how this ever worked. But no-one has energy or incentive to investigate that.

• Something deeply weird is happening in stripes-webpack to cause the "m is undefined" error. The WebPack extension is picking up ui-plugin-eusage-reports OK, but in the object representing it the getModule method returns undefined for some reason. No recent changes in stripes-webpack look even remotely relevant.

• This happens only when loading our plugin from a workspace, not when downloading it from the NPM repository. This is good news, as it means that releases should work even if development is a mighty pain.

• The same problem does not seem to strike for other plugin modules such as ui-plugin-find-user or for other handler modules such as ui-servicepoints, both of which load from a workspace just fine.

• However I can make things work by manually removing the NPM-fetched copy of ui-plugin-eusage-reports from my platform's node_modules directory and replacing it with a git checkout which I can then work on. This gives me a way to do actual work.

• It does not work if instead of moving my git checkout into node_modules I make a symlink to it there. Which makes it even more confusing.

The bottom line here is that finally, after three totally unproductive days, I have a development environment which I can use to do actual work.

I am now using a completely different approach; and while it is not working, it is failing in what I think is a better way. Rather than building a workspace that contains both a platform and the plugin (the original approach), or running the plugin in a context that includes its invoking app (the second approach, described in the last three comments), I am now building a platform directly, but modifying its package file to tell it to get the plugin from the local filesystem.

Specifically:

This results in a bundle which can be visited at localhost:3000, and where the Settings --> System information --> Software versions page shows @folio/plugin-eusage-reports 2.0.0 – so far, so good!

And going to the eUsage application and clicking on the JSTOR usage data provider shows a title-matching summary from the plugin just fine.

But going to the Agreements application and clicking on the Index Data test agreement shows a typically useless error message:

Error: Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports. Check the render method of `Agreement`.

But the good news is that I think this really is the core error involved in invoking ui-plugin-eusage-reports as a handler, rather than one of the many many other errors that have cropped up throughout this process. So it should be possible to debug this.