Adding a plugin resource like so
<resource type="download" name="test.js" location="test.js"/>
works perfectly fine.
But as soon as I try to add a file with the .map extension I get a 503 from Tomcat instead of the requested file.
<resource type="download" name="test.js.map" location="test.js.map"/>
This is important because source maps are stored with the .map extension. Does anyone know why this is happening?
Last time was looking into this, Jira was handling .map files in special way. We worked around that by changing source map extension to something else in webpack configuration.
I wonder why Jira is handling .map files in a special way and if it can be configured to be turned off during development. The compiler we’re using has the .map extension hardcoded so we’re currently not able to change the extension to something else.
The Atlassian web resource manager does treat sourcemap files specially and it expects JavaScript files to come in .js and .js.map pairs.
The WRM is responsible for batching JavaScript together, so it will take a bunch of your source .JS files, slap them all together into an appropriate batch, and process and spit out a corresponding .map file for the entire batch. For this reason, the synthesized .map contains a sourcemap for all of the constituent JS files, including new line and column numbers that map the mangled batch .JS back to the source line numbers.
In theory, you aren’t supposed to define a separate <resource> for the .map file at all–it’s supposed to just work. My practical experience is that even when you get all of that working, Chrome has difficulty correctly and consistently interpreting the line and column numbers of a huge minified batch, and so the source maps never really worked correctly for me.