Skip to content
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

Fallbacks and future API #24

Open
jkrems opened this issue Sep 17, 2019 · 1 comment
Open

Fallbacks and future API #24

jkrems opened this issue Sep 17, 2019 · 1 comment

Comments

@jkrems
Copy link

jkrems commented Sep 17, 2019

Even though import maps may drop fallbacks in the initial version, I still believe that being able to feature detect and/or load fallbacks is important. Adding exports as mentioned in other issues (#3) makes this harder. Could the proposal call out alternatives for future API extensions? My current assumption is that import 'lib:uuid/UUID' would be easier to handle than a named export since simple string-based fallbacks could catch it already.

@littledan
Copy link
Member

I think there's a lot of possible design space for adding features to import maps. I don't think we're at the point where we should be designing libraries to cope with their restrictions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants