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
I like the new config-based way we're specifying exports and dependencies in the new legacy loader. One of the things it fixes is that it eliminates the !order and !exports suffixes on the module ids necessary with the js! plugin. The css! plugin also uses suffixes (as well as allowing comma-separated ids which has the same consequences).
Removal of these suffixes, in turn, eliminates the need to have a normalize method on the plugin. And, finally, as we're coming to discover, the proposed ES6 module loader will not allow async normalization.
In short: the current js! and css! plugins won't work seamlessly in ES6 land because of their module id suffixes / normalization rules.
We should probably plan to break backwards compatibility on these plugins at some point, but maybe we should also investigate a css loader that allows the user to specify dependencies (for proper cascading) and an export (to allow the plugin to verify that the stylesheet is loaded in Chrome 14+ and Safari 6).
While we're at it. Why not a text loader, too?
Any thoughts? Comments?
The text was updated successfully, but these errors were encountered:
I like the new config-based way we're specifying exports and dependencies in the new legacy loader. One of the things it fixes is that it eliminates the !order and !exports suffixes on the module ids necessary with the js! plugin. The css! plugin also uses suffixes (as well as allowing comma-separated ids which has the same consequences).
Removal of these suffixes, in turn, eliminates the need to have a
normalize
method on the plugin. And, finally, as we're coming to discover, the proposed ES6 module loader will not allow async normalization.In short: the current js! and css! plugins won't work seamlessly in ES6 land because of their module id suffixes / normalization rules.
We should probably plan to break backwards compatibility on these plugins at some point, but maybe we should also investigate a css loader that allows the user to specify dependencies (for proper cascading) and an export (to allow the plugin to verify that the stylesheet is loaded in Chrome 14+ and Safari 6).
While we're at it. Why not a text loader, too?
Any thoughts? Comments?
The text was updated successfully, but these errors were encountered: