Handle sourceMappingURL already prefixed with asset path

[tagCincy]

When using a build system, specifically esbuild and referencing assets such as images, you must set a publicPath configuration. This allows assets to be fetched for the appropriate endpoint (eg. image.png --> assets/image.png) when rendering a page. In addition to images being called from url(), setting the publicPath also sets the sourceMappingURL comment to the prefixed path. Because of this added prefix, Propshaft removes the sourceMappingURL comment from the minified JS asset as the path cannot be correctly resolved.

This change will remove the prefix if the source_mapping_url prior to rewrite of the comment.

[brenogazzola]

This seems to be addressing the same problem as #150. Or is it something else?

[brenogazzola]

If it is, I'm more inclined with going with this solution, instead of allowing the regex to swallow everything that is not the asset name in a non capturing group.

[tagCincy]

Yes it is

[brenogazzola]

Why did you close it? This seems like the better solution compared to #150

[tagCincy]

Reopened. I found a monkey patching solution to unblock me.

[brenogazzola]

Thanks!

[lvangool]

We're caught by this too - any ideas when the next cut of propshaft will be published?

[brenogazzola]

I'll ask, but for now you can simply change your Gemfile to point to the correct commit in the main (which is what the new gem would use)

gem "propshaft", github: "rails/propshaft", ref: "8fb8f7c9cb63c16b381dad47b69a36fd67837985"

Or if you prefer, point to main (which is what I do):

gem "propshaft", github: "rails/propshaft", branch: "main"

[lvangool]

@brenogazzola thank you! We're not keen to run a version that isn't also being run by thousands of other people; would be great to have an indication of when an official cut is scheduled 🙏🏻

[lvangool]

@brenogazzola any chance you managed to get an approximate release date?

[pfeiffer]

Would love to see this included in a release!