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
But for an inline loader, there seems to be only one way to pass "options", and it involves polluting the LoaderContext namespace used by every loader. Example config:
{loader: {foo: 'bar'},
…
}
The above "loader" config property does not scale well. Eventually two loaders will use the same loader property name, but define it to mean different things.
What does the proposed API of configuration look like?
What problem does this feature solve?
A "regular" loader can be passed options via module rules. For example:
But for an inline loader, there seems to be only one way to pass "options", and it involves polluting the
LoaderContext
namespace used by every loader. Example config:The above
"loader"
config property does not scale well. Eventually two loaders will use the sameloader
property name, but define it to mean different things.What does the proposed API of configuration look like?
Proposed:
The text was updated successfully, but these errors were encountered: