Extension-based loading strategy #234
Milestone
Comments
briancavalier
added a commit
that referenced
this issue
Oct 14, 2013
Experiment with simplest-possible extension-based loader configuration. The ext plugin maps file extensions to plugin other plugin loaders to allowing loading things like html, css, text, json, locale files, etc. without explicitly using a plugin id. Still more to do here, like how to use this without having to specify ext! everywhere (which kinda defeats the purpose!) See #234
|
After discussion w/@unscriptable, I added a simple experiment in the extension-based-loading branch. It's a plugin that delegates to other plugins by transforming resource ids based on their extension. It works great, but requires that you either explicitly use it as a plugin, e.g. It'd be nice if this were mostly invisible, but we still need to work that out. |
This was referenced Oct 15, 2013
|
Any progress with this at all? :D |
|
Sorry, @gehan. Not much time lately. :( |
|
No probs! Was mainly of interest for relative paths in specs which seems to be possible in the newest develpments! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It'd be great to support loading different types of resources based on file extension, or module id pattern matching. Also, AMD plugin syntax, or the like, will not be supported as a first-class syntax in ES6 module loaders, so that's an indication that an AMD-like plugin approach probably is not the future. Using Extensions and/or pattern-matching is also closer to how Node's
requireextensions work.The text was updated successfully, but these errors were encountered: