Was access to unminified JS code via cdn-dev.sstatic.net deliberately removed?

Question

It used to be possible to access the unminified versions of (most) Stack Exchange JS files via cdn-dev.sstatic.net (as opposed to the usual cdn.sstatic.net host that serves the minified versions). It was a kind of a "hidden feature", and not very widely documented, although it's mentioned e.g. in this old Blog Overflow post.

For example, the unminified version of https://cdn.sstatic.net/Js/full.en.js used to be available at https://cdn-dev.sstatic.net/Js/full.en.js. For anyone curious, here's an archived copy from 2016 showing what it used to look like.

However, while trying to see if I could help investigate the cause of this bug that I reported earlier today, and maybe suggest a fix for it, I noticed that this no longer seems to be the case: now both hosts serve the same minified code.

Obviously, Stack Exchange isn't under any obligation whatsoever to give its users access to such internal development resources like unminified JS code. If they don't want to let us see them any more, that's their choice to make. But losing this access is definitely going to make it harder for the community to assist SE in diagnosing and fixing bugs, and also makes it a lot harder to develop user scripts and browser extensions that interact with the Stack Exchange UI. Personally, I'm hoping this is just an unintentional glitch, and that Stack Exchange will continue to provide us access to these files. But if it's intentional, it would at least be nice to know that.

Answer 1

A little background: when the Q&A application spins up it initializes individual site settings which includes probing a bunch of file paths to check for existence of certain assets (e.g. email logo PNGs, SVG logos, etc.). Also, when rendering a linked resource in a page (JS, CSS or images) we have to load the resource, SHA1 hash it and then use that SHA1 to create the cache breaker to tack on to the end of the URL. That ensures our resources get freshly pulled by our CDN (Nick has more detail on that process here).

All that adds up to a big pile of file system hits (thousands of assets, hundreds of SE network sites). We're about to add more things to that pile so we decided that we can easily generate a JSON file containing pre-computed hashes during our asset compilation process and if that file is present, use the hash from that instead of hitting the file system to generate.

That change involves touching the asset compilation scripts and while we were there we noticed what we thought was a bug in the processing of JS files. Notably that if we didn't pass the --minify flag it went and dumped a bunch of JS in files called blah.js.min. That seemed crazy so we killed it and allowed it to overwrite the .js files instead. Except that meant minified copies of the JS were copied upto dev when we weren't expecting them to be.

Intuitively, not specifying the --minify flag shouldn't bother to minify the JS at all, but we do want to minify during the dev build so that we catch JS uglification errors as early as possible. We just don't wanna output the minified JS anywhere because it makes debugging on dev a hell of a lot easier.

So, I just pushed a change that makes sure we don't attempt to output anything unless we really want the minified JS (i.e. prod).

Apologies for the inconvenience, unminified output is now back on dev \o/

Note our CDN has cached the minified output for the URL without a cache breaker; you'll need to add a cache breaker to get the unminified output until the cache expires (e.g. https://cdn-dev.sstatic.net/Js/full.en.js?v=0c6a7b0e942a)