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
Configuration merging is a bespoke feature that was only added here to simply maintenance of UserFrosting's Sprinkle plugin system. The system operates on a few rules;
replace where new incoming bundles replace those already defined.
merge where 2 bundles are combined. styles and scripts arrays are merged manually via Set, everything else is left up to the jest-extend library.
ignore where new incoming bundles are discarded if they collide.
error where collisions trigger a failure.
The chosen rule is defined by the incoming bundle, defaulting to replace.
This is a lot of logic to maintain, and the primary consumers (UserFrosting developers) would expect that bundling logic is tied to their version of UserFrosting (it is, compatibility is managed via semver).
This style of asset management is very much on the way out but is likely to see continued use in niche scenarios. Keeping the cost of ownership low (minimum API surface, lockdown the feature set, but keep what is offered flexible) is the goal looking forward.
The text was updated successfully, but these errors were encountered:
Configuration merging is a bespoke feature that was only added here to simply maintenance of UserFrosting's Sprinkle plugin system. The system operates on a few rules;
replace
where new incoming bundles replace those already defined.merge
where 2 bundles are combined.styles
andscripts
arrays are merged manually viaSet
, everything else is left up to thejest-extend
library.ignore
where new incoming bundles are discarded if they collide.error
where collisions trigger a failure.The chosen rule is defined by the incoming bundle, defaulting to
replace
.This is a lot of logic to maintain, and the primary consumers (UserFrosting developers) would expect that bundling logic is tied to their version of UserFrosting (it is, compatibility is managed via semver).
This style of asset management is very much on the way out but is likely to see continued use in niche scenarios. Keeping the cost of ownership low (minimum API surface, lockdown the feature set, but keep what is offered flexible) is the goal looking forward.
The text was updated successfully, but these errors were encountered: