After a Sprockets 4.x upgrade the CSS sourcemaps seemed to be assuming ASCII-8BIT and causing errors within the asset pipeline for SCSS which contained Unicode chars due to corruption going through the pipeline.
After a bit of digging, it seemed that was caused by an equivalent issue to #669 except for SCSS with Unicode in it (Encoding::UndefinedConversionError at "\xC3" from ASCII-8BIT to UTF-8). This is an issue only when debug: true is enabled for an asset and thus with sourcemap generation enabled.
In #669 (4.1.0) the default charset for JS sourcemaps was corrected to UTF-8. However the default charset for application/css+sourcemap+json is still currently ending up as ASCII-8BIT, even when source has a non-ASCII character in it. For consistency and correctness, it seems that these should also be assumed to be Unicode.
After a Sprockets 4.x upgrade the CSS sourcemaps seemed to be assuming ASCII-8BIT and causing errors within the asset pipeline for SCSS which contained Unicode chars due to corruption going through the pipeline.
After a bit of digging, it seemed that was caused by an equivalent issue to #669 except for SCSS with Unicode in it (
Encoding::UndefinedConversionError at "\xC3" from ASCII-8BIT to UTF-8
). This is an issue only whendebug: true
is enabled for an asset and thus with sourcemap generation enabled.In #669 (
4.1.0
) the default charset for JS sourcemaps was corrected to UTF-8. However the default charset forapplication/css+sourcemap+json
is still currently ending up asASCII-8BIT
, even when source has a non-ASCII character in it. For consistency and correctness, it seems that these should also be assumed to be Unicode.This PR also reinstates the changelog for the previously-released
4.1.1
which seemed to have been (accidentally?) removed in https://github.com/rails/sprockets/commit/17d77237f60aa0c2c339e414b2efd3a658a872e7 This was rather confusing when reading the changelog.