You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This fixes #18438 by allowing module rules to opt-in to alternate asset module handling behavior where they are treated more like JavaScript modules (in the sense that the asset module content is treated as text instead of binary, and any applicable source maps are included just like they would be for JS modules).
The motivation behind this change is to allow for loaders such as sass-loader to be used to compile source files into Asset Modules (instead of, e.g., chaining with css-loader + style-loader) while still retaining valuable source map information that such loaders are capable of producing. For example, a project may want to compile SCSS entry points into static CSS files emitted to the public path of the site, with .css.map files produced alongside those .css files during development.
What kind of change does this PR introduce?
This adds a new binary option to the generator options for asset, asset/inline, and asset/resource modules. This option can be specified to override the this.binary property on NormalModule that is automatically set to true for Asset Modules. Overriding an Asset Module to binary: false allows source maps that are produced by the loader chain to be included with the output of an asset module just like for JavaScript modules.
Did you add tests for your changes?
A new configCases test was added in asset-modules/keep-source-maps to test this new functionality.
Does this PR introduce a breaking change?
There should be no breaking changes, as the new behavior is explicitly opt-in. If the new option is not supplied to the generator options, the behavior is identical to before.
What needs to be documented once your changes are merged?
The new binary option on generator for Asset Modules. I assume that would be here at a minimum.
The text was updated successfully, but these errors were encountered:
A pull request by @ArcanoxDragon was merged and maintainers requested a documentation change.
See pull request: webpack/webpack#18457
This fixes #18438 by allowing module rules to opt-in to alternate asset module handling behavior where they are treated more like JavaScript modules (in the sense that the asset module content is treated as text instead of binary, and any applicable source maps are included just like they would be for JS modules).
The motivation behind this change is to allow for loaders such as
sass-loader
to be used to compile source files into Asset Modules (instead of, e.g., chaining withcss-loader
+style-loader
) while still retaining valuable source map information that such loaders are capable of producing. For example, a project may want to compile SCSS entry points into static CSS files emitted to the public path of the site, with.css.map
files produced alongside those.css
files during development.What kind of change does this PR introduce?
This adds a new
binary
option to thegenerator
options forasset
,asset/inline
, andasset/resource
modules. This option can be specified to override thethis.binary
property onNormalModule
that is automatically set totrue
for Asset Modules. Overriding an Asset Module tobinary: false
allows source maps that are produced by the loader chain to be included with the output of an asset module just like for JavaScript modules.Did you add tests for your changes?
A new
configCases
test was added inasset-modules/keep-source-maps
to test this new functionality.Does this PR introduce a breaking change?
There should be no breaking changes, as the new behavior is explicitly opt-in. If the new option is not supplied to the generator options, the behavior is identical to before.
What needs to be documented once your changes are merged?
The new
binary
option ongenerator
for Asset Modules. I assume that would be here at a minimum.The text was updated successfully, but these errors were encountered: