-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extensibility? #9
Comments
Breaking the declarative format would be very bad, IMO. This format will need to be written and read by a number of tools in different languages. IDEs will need to read it to find imports and offer intellisense, etc. Web servers will need to read it to do server push. Package managers and build systems like Bazel and Buck will need to write it. Not all of these can easily or performantly execute JavaScript functions. |
I think https://github.com/domenic/package-name-maps#a-programmable-resolution-hook covers this. |
Yeah, this is covered in the readme :). It's not really a feasible direction for running in web browsers. Additionally, this proposal is very strict on restricting itself to name resolution, and not any kind of source transformation. I think there could still be future ways to register custom Content-Type processors/source transformers, but it wouldn't be part of this proposal, and would have a lot of issues of its own to work out. So, let's close this. |
Are there any ideas around building in natively extensibility the way that Webpack builds into imports? Meaning: could there be a way in which a named map (or a matched regex) returns not a path but can point to a function that returns a resource? It would break the JSON format but IMO using JSON is limiting. It should probably be something more imperative like the way Custom Elements are registered, and could then support scenarios like returning JS imports from, say,
import styles from "styles.css"
or to provide other extensibility.The text was updated successfully, but these errors were encountered: