| 03:55 | <Jack Works> | I heard import defer * as ns has changed to import defer ns is that happening? |
| 07:31 | <nicolo-ribaudo> | No, where did you read it? |
| 15:57 | <nicolo-ribaudo> | I'll probably be 5 minutes late |
| 16:00 | <annevk> | littledan: syntax for meta.resolve() or a different attribute makes a bit more sense to me than overloading type |
| 16:01 | <annevk> | littledan: at least as currently specified we end up fetching everything with type and this url thing would create quite the code smell I think |
| 17:00 | <littledan> | I don't remember us discussing overloading type much in this group. I agree that it's code smell to use that particular attribute. I'd at least use another key |
| 17:00 | <littledan> | We've mostly discussed syntax like import asset foo from "./foo.jpeg"; or something |
| 17:01 | <littledan> | Kris didn't like that syntax because he found it ambiguous between whether foo was a URL or the bytes |
| 17:01 | <littledan> | even if it's the bytes: we still need the type so that the fetch can be done properly |
| 17:17 | <Kris Kowal> | Is asset bytes or URL in that case? |
| 17:18 | <Kris Kowal> | Also, is the underlying Module paused before fetch or after? |
| 17:20 | <Kris Kowal> | I presume that import bytes from './bin.oct' with { type: 'bytes' } implies a content-type of application/octet-stream and is as such sufficient to go as far as fetch especially, especially since there’s no possibility of advancing to evaluation behavior. |
| 17:21 | <Kris Kowal> | I presume also that import text. from './text.txt' with { type: 'text' } implies a content-type of text/plain; charset=utf-8 and is also sufficient to go to fetch. |
| 17:24 | <Kris Kowal> | Whereas import url from './image.jpg' with { type: 'url' } implies nothing about the content-type and wouldn’t advance to fetch in any case. Using a different key introduces confusion about the role of type in import asset imageUrl from './image.jpg' with { type: 'jpeg' } (it would just produce a different memo key) |
| 17:25 | <Kris Kowal> | Or, alternate strawpoke, type would be vestigial in import imageUrl from './image.jpg' with { type: 'jpeg', phase: 'located' }. |
| 18:02 | <annevk> | Kris Kowal: I was thinking we might ignore the Content-Type response header for some of these types, as fetch() does. Requiring a Content-Type like CSS module scripts do would make them not as useful I think. |
| 18:05 | <annevk> | Kris Kowal: why would it need type at all? import url from 'test' with { gimme: 'url' } |
| 18:20 | <Kris Kowal> | The question is not whether the type is needed, but what it would mean if it happened to be provided. |
| 18:23 | <Kris Kowal> | e.g., { gimme: 'url', type: 'css' } and { gimme: 'url', type: 'json' } would give you the same URL twice, but have two entries in the modules memo and do the work twice. Whereas, { type: 'url' } would ensure only one memo entry. |
| 18:23 | <Kris Kowal> | But this is a small thing I’m not hung up on. |
| 18:28 | <littledan> | Is |
| 18:34 | <bakkot> | import.meta.resolve has been adequate for me; I would be a little hesitant to introduce a second way of doing that |
| 19:20 | <Mathieu Hofman> | Isn't import.meta.resolve intrinsically a dynamic API that wouldn't allow preprocessor / bundlers to understand and map which assets need to be part of a deployment artifact? There ought to be a reason that all bundlers currently go the import './foo.css' route to reference external assets. |
| 19:24 | <bakkot> | only if you use it in a dynamic way |
| 19:25 | <bakkot> | if the bundler is relying on it, it can easily error if you pass it a non-constant or factor it out into a variable |
| 19:25 | <bakkot> | at least part of the reason they all use the import './foo.css' syntax is because that design decision predates the existence of import.meta.resolve |
| 20:52 | <ljharb> | it also predates dynamic import. |
| 22:08 | <Justin Ridgewell> | We could solve that by making an import.resolve() meta function |
| 22:10 | <Justin Ridgewell> | But we should be able to support both as long as it explicitly matches import.meta.resolve() (or some trivial static analysis of const meta = import.meta; meta.resolve() |