Warn instead of error for missing sourcemap files during collectstatic

[blighj]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

When post_processing js/css files during collectstatic with ManifestStatifilesStorage it should warn about missing sourcemap files instead of raising an error and preventing and further processing of files.

Problem

It can happen that you install a third party lib, and only include the main js/css file in your static directory. The file points to a sourcemap file, but you haven't downloaded it, as it's not something you are overly concerned about, especially if you are a beginner. But when you run collectstatic you end up with a confusing error (that we have tried to improve recently). It would be better to give a warning and let the rest of the collectstatic work.

This also affects third party django apps, after doing an audit of djangopackages I found several that include /static folders with files referencing missing sourcemaps. So a developer who wants to use their project and ManifestStatifilesStorage has to know how to use the the --ignore option of colelctstatic, or how to add a /static path to the sourcemap mimicing the static structure of the third party app, as they have no way other than a bug report to change the actual js/css.

Request or proposal

proposal

Additional Details

There is a similar problem with local build js files in your /static folder when using the support_js_module_import_aggregation option. A warning approach could be used when encountering those import * from "./jquery" during collectstatic.

I still think it makes sense to raise the error for missing images, font files, actual css/js imports, etc. As in those cases their is a high probability chance that your project's frontend won't work without the assets and it's good to be told straight away.

Implementation Suggestions

There is prior art implementation in https://github.com/blighj/django-manifeststaticfiles-enhanced/

[github-actions]

Thank you blighj for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[codingjoe]

@blighj while your markdown needs a little polishing, I am all for this change. If you want backward compatibility, might I suggest a --ignore-errors argument?

[jacobtylerwalls]

Yep, this was proposed several times in https://code.djangoproject.com/ticket/21080 (OP, comment:32, comment:43), and makes a lot of sense, particularly in the --ignore-errors mode.

[blighj]

Hopefully you wouldn't need an --ignore-errors option as a workaround for the false positives now that 21080 and its sister ticket 36969 are solved 🤞.

So before too much momentum builds for the flag. I'm pitching that for the sake of beginners, sourcmaps in particular should only raise warnings, so the out of the box experince when you use some lib but don't have its sourcmap is not so harsh.

I'm +0 on the flag myself, if we had everything else working you shouldn't need it, but as stated in various places the regex's will always have error cases, so the flag might help then. I'm just hopefull they will be much rarer now. (That may be motivated reasoning.)

[codingjoe]

Hm... Django has to be secure by default. So if the error / warning doesn't expose the devs to additional risks both in terms of security or otherwise shooting themselves in the foot, I guess a default warning level would be ok. Either way, your efforts should make this nearly obsolete.