> Another failure I see is the fact that the "type" property is not meant to be used for this type of language augmentation, it's meant to describe the type of the file without inferring from the file extension
It sounds like you’re confusing Import Attributes with Import Assertions, which was the previous iteration of Import Attributes.
Interpretation of import attributes is host defined. For Import Assertions, that wasn’t true - they were intended never to impact runtime evaluation. That’s the difference with Import Attributes. Import Attributes do impact runtime evaluation.
This turns what looks like a function call in the importer into something like macro expansion (it doesn't look like actual macros though).
The only inconsistency is that Bun is front loading some of these effects to the server/bundler runtime and effectively memoizing the equivalent behavior before it reaches a client. But it’s not doing that of its own volition, it’s doing it to address an explicit attribute in the source code.
The only way this would be a meaningful problem is if the explicit value has a chance of colliding with either existing code in the ecosystem (highly unlikely, no one is really using this syntax yet except perhaps in an equally experimental context), or some plausible pending standard (unless one was proposed in the last couple weeks, I’m pretty sure I can rule that out too).
I share other commenters’ lament that this is not a true macro solution (and I think it should actually just be renamed to something like comptime). But I don’t think this deserves the deviation-from-standards challenge it’s getting in this thread. And lest I come off as a Bun fanatic, I think I’m one of the people who more frequently questions potential Bun spec deviations when they come up on Twitter.
https://bun.sh/blog/bun-macros#how-it-works
So the worry about having legacy anti-spec things still seems pretty valid.
Specification and implementation are chickend-and-egg.
B. If you blur the line between "runtime" and "compiler", you'll realize that a lot of JS ecosystem (e.g. Babel) run ahead of that.