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

There should be an escape hatch to allow unknown import attributes #132

Open
gibson042 opened this issue Mar 14, 2023 · 3 comments
Open

Comments

@gibson042
Copy link

Now that #131 has established a requirement for implementations to reject unknown attributes, deferring the upgrade concerns of #21 (comment) and #56 (comment) is more hazardous. As suggested in #131 (comment) , I think it would be valuable to add an escape hatch allowing authors to explicitly indicate that particular import attributes should be ignored when they are unknown to an implementation. It would be logically similar to the ! criticality flag of the IETF timestamp suffixes draft, but with reversed polarity. As a strawperson, @nicolo-ribaudo suggested syntax like with { type: "css", layer?: "utilities" } or with { type: "css", "layer?": "utilities" }.

And a final point noted at #131 (comment) :

an alternative design could involve consideration of not just the attribute name but also the value, such that a new implementation might want to reject import "./image.png" with { type: "image", "as?": "not-yet-shipped-format" } while an old implementation that doesn't even know about as would treat the import like with { type: "image" }. But that kind of variance doesn't seem helpful in either the name-only or the name-and-value design anyway. It's worth noting that neither design is fully general with respect to fallback, but I'm just striving for a bridge to something better while the range of valid values for any particular attribute has not been subject to many changes and thus that lack of generality isn't detrimental.

@ljharb
Copy link
Member

ljharb commented Mar 14, 2023

I think that it's very important there not be an escape hatch - giving the ecosystem carte blanche to throw whatever they like in here risks fragmenting the language.

@gibson042
Copy link
Author

The proposal already allows each implementation to define its own list of supported attributes: https://tc39.es/proposal-import-assertions/#sec-hostgetsupportedimportassertions

This suggestion wouldn't change that. It would, however, allow a way for new assertions to be added without requiring fragmentation of source files.

@juner
Copy link

juner commented Mar 29, 2024

@gibson042 Maybe the link has changed to this?
https://tc39.es/proposal-import-attributes/#sec-hostgetsupportedimportattributes

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

3 participants