This revealed a minor gremlin in the latest OpenLayers. I have opened a PR to fix that: openlayers/openlayers#11224

That is an excellent idea! Much more JS-idiomatic. The existing package.json is a bit sparse, so I'd need a bit of a pointer on how to get started?

Using package.json/yarn would be reasonable, but our deployment doesn't handle that at this time, so it would need some puppet work.

I think, for the time being, we could update package.json and then manually run yarn install --modules-folder foo/bar. That would leave us with vendored deps in the repository and an easy way to manually update them. Also dependabot could check for newer versions etc. That would allow us to bypass puppet for now.

https://classic.yarnpkg.com/en/docs/cli/install/#toc-yarn-install-modules-folder

@mohawk2 it should just be a matter of running yarn add to update package.json and add the appropriate entries to yarn.lock. See https://classic.yarnpkg.com/en/docs/usage

Now there is a yarn script, utilised by bin/update-deps, that rebuilds the ol-using JS. The generated JS file, despite the doomy warnings of webpack because it's ~250k, is still about a third of the previous version, because it only incorporates what it actually uses. It's still checked into git for the present time.

This PR should also show the way towards auto-building / updating all our other JS code too (move them into js-src, add to webpack.config.js for building back into static/js). From here, I believe the way forward would be to generate all the relevant assets, which would then be incorporated in the -web Docker image.

This requires committing build artifacts to the repository, which I am not a fan of. It also doesn't set up the built files to be properly cacheable.

What errors were you seeing with the tooltip and dropdown menu code? I don't see any errors, but either way just wrapping them in a try is the wrong approach.

It seems the tooltip/dropdown errors were just caused by the map having failed to load due to other problems. They don't appear now, and the JS changes to suppress them have been dropped.

This PR is now in somewhat of an intermediate state - it updates the vendored and versioned ol.css, albeit from the unminified version in node_modules. Obviously the end-state is for that CSS plus the generated tree-shaken mirror.js to not be committed anymore, and to have hashed names suitable for eternal caching (I assume webpack makes that easy). I gather for that to work, then currently yarn would need to be on the production machines? Else yarn would just need to be on the machine that creates the Docker image, possibly that would be in the GitHub workflow.