Reconsidering how we provide CSS/JS to non-NPM consumers

I’m not comfortable with the idea of building and serving non-version-locked JS and CSS assets directly from eclipse.org for external use.

First, these files are rebuilt on every deployment. If something goes wrong during a deployment, the assets can disappear or break, which means anyone relying on them immediately ends up with broken JS/CSS.

Second, serving “latest” assets exposes users to breaking changes. Without version locking, consumers have no stability guarantees and can’t safely depend on our files.

Third, this adds unnecessary complexity to the eclipse.org Hugo build. Maintaining asset-serving functionality feels out of scope for what the Hugo repo should handle. Its role should be to provide HTML/CSS for the site... not act as a library distribution system.

Finally, our build process is already getting heavy. We frequently hit memory issues, local builds are slowing down, and deployments take longer. We’re trying to do too much in this pipeline.

Proposed Solution

Use unpkg for asset distribution. While it is a CDN (I know we're against using those...), it directly serves files from our NPM packages at explicit versions. It’s fast, reliable, zero-maintenance, and integrates naturally with our existing NPM workflows. Versioned URLs ensure stability for anyone consuming our assets.

Example: https://unpkg.com/eclipsefdn-solstice-assets@0.2.0/less/styles.less

This gives us a clean, predictable workflow without adding more burden to our infrastructure.

Note We will need to begin shipping built JS and CSS in EFSA instead of only serving source code. This does not mean we need to commit our built files. Of course, you can make NPM build these files before they package your library into a tarball.