Use extensible object syntax?

[jonathantneal]

Would you be open to using an extensible key/value format, to future-proof reflection in case it's needed for other use cases, even though none are implemented now?

import JoyStyle from "./joy.css" as { type: "css", media: "(width > 640px)" }

[justinfagnani]

I think the media example is really compelling! Whether it fits into import reflection or not I think the use case should be strongly considered within the realm of imports in general, and it's probably a good idea to consider how it intersects with reflection and assertions and whether we want potentially three related import features: assertions, reflection, and something else (attributes?).

As CSS module scripts are a way for a JS module to depend directly on CSS, it somewhat takes the place of <link> but embedded in the module graph rather than in the top-level HTML. However imports are missing some features of <link> notably the media attribute.

Adding a media attribute would enable a form of conditional imports that close the gap with <link>. I'm not sure where else conditional static imports might have been discussed, but I could see something like this:

import * as desktopStyles from './desktop.css' assert { type: 'css'} with { media: '(width > 640px)' };
import * as mobileStyles from './mobile.css' assert { type: 'css'} with { media: '(width <= 640px)' };

if (desktopStyles !== undefined) {
  document.adoptesStyleSheets.push(desktopStyles.default);
}
if (mobileStyles !== undefined) {
  document.adoptesStyleSheets.push(mobileStyles.default);
}

[jonathantneal]

Other potential examples in some distant future might include:

import boldOpenSans from './OpenSans-Bold.woff' assert { type: 'font' } with { weight: 700 }

await boldOpenSans.load()

import bgm from './background-music.flac' assert { type: 'audio' } with { loop: true }

bgm.addEventListener('canplaythrough', () => {
  bgm.play()
})

import myWorker from './my-worker.js' with { type: 'worker' }

myWorker.postMessage({ cmd: 'start', msg: 'Hi' })

[devongovett]

I think it would be great if a more extensible syntax were used rather than requiring a parser change each time a new attribute is introduced. There are a lot of potential use cases for import attributes, and I don't think it always necessarily makes sense for each one to go through the TC39 process since they won't be implemented by all engines (e.g. some attributes might not make sense in browsers). I raised this back on the import assertions proposal as well, and a number of good use cases came up there: tc39/proposal-import-attributes#99.

For example, one thing that would be cool is support for preload/prefetch attributes. For example, something like this:

import foo from "./foo.js" with { load: "prefetch" };

// some time later...
const exports = await foo.get()
// or maybe
const exports = await import(foo);

Somewhat related: #16.

[guybedford]

@devongovett I wonder if a usecase like preload might not be better suited to a dedicated import.preload function in due course over attributes. Are there specific reasons you'd want attributes over a dynamic mechanism here?

[devongovett]

Yeah might also be useful for some cases, e.g. on-demand preloading when a user hovers over a link.

I think one benefit of attributes is that they are much more easily statically analyzed. This not only benefits build tools, but could potentially benefit browsers and other runtimes as well. A quick pass could be done to determine what to preload without parsing and evaluating the entire module.

Btw, this was actually @littledan's idea, and there was some prior discussion about it here.

Another potential use case is lazy loading, i.e. subsuming https://github.com/tc39/proposal-defer-import-eval.

[ljharb]

import.preload(specifier) would be just as statically analyzeable as import(specifier), as well as lintable (if you want to restrict it to a static specifier), no?

[devongovett]

Yeah, but you have to evaluate the code to know when to preload, whereas a declarative import statement allows immediate preloading without fully parsing or running any code. Browser engineers could tell us if that's useful, but seems like it could be (esp if it supported non-JS resources, i.e. subsuming asset references - #16).

I also like the idea that it could be done the same way either as an import statement or a dynamic import.

import foo from "./foo.js" with { load: "prefetch" };

import('./foo.js', {with: {load: 'prefetch' }});

[ljharb]

Given that import.preload would be syntactic, it would show up on a first parse (which engines have to do anyways to hoist import statements), so it doesn't seem like there'd be a need to run any code if the argument is a static string.

[guybedford]

<link rel=modulepreload> is the early hint for browsers, and is preferable to discovered preloads (which involves latency) for the static case.

[devongovett]

Sure, for initial page loads but would be nice to have a way to preload things for later loaded things other than insert one of those into the document manually.

Anyway, this is all kinda off topic. I am mainly interested in having a syntax that is forward compatible with future additions, as well as extensible for build tools to innovate in this space without waiting for TC39.

[guybedford]

Sure, for initial page loads but would be nice to have a way to preload things for later loaded things other than insert one of those into the document manually.

This is a great discussion and one I would love to have further.

Anyway, this is all kinda off topic. I am mainly interested in having a syntax that is forward compatible with future additions, as well as extensible for build tools to innovate in this space without waiting for TC39.

I don't think it's at all off-topic, we should discuss features in the context of use cases. The more use case discussions the better.

[jonathantneal]

I don't think it's at all off-topic, we should discuss features in the context of use cases. The more use case discussions the better.

I appreciate the optimism, and what you write is true, but it’s also incomplete. For me, a single extensible API is important because 1. I’m concerned TC39 folks might not understand the needs of source file tooling where I want to innovate, and because 2. a single extensible API can be delivered in a more timely manner than several divergent APIs.

Concern 1

I’m not super encouraged to lean into a conversation about use cases if I’m concerned it won’t go anywhere.

• Watching as a build tool author’s 2020 thread fizzles in 2 weeks, I sense a fleeting interest in understanding my environment.
• Watching as a TC39 delegate dismisses another build tool author, I sense an outright lack of interest in understanding my environment.

I’m not super encouraged to lean into a conversation about uses cases if I’m concerned delegates and advocates misunderstand my environment, anyway.

“Content type on the local FS can only be derived from file extensions.”
— https://twitter.com/lcasdev/status/1495743689930457095

”Do you not have file extensions?”
— https://twitter.com/justinfagnani/status/1481446609128865796

Meanwhile...

”... the only change i do now is .js > open all files as > javascript > jsx. that’s all”
— https://twitter.com/dan_abramov/status/1488956873390923780

“In Next.js, a page is a React Component exported from a .js, .jsx, .ts, or .tsx file”
— https://nextjs.org/docs/basic-features/pages

Concern 2

I see a not insignificant number of features that would require different keywords to accomplish what we want from one.

---

Still, here’s another 'transform' use case I was reviewing, borrowing Justin’s syntax:

import images from './profile.jpg' as 'image-set' with { size: [ 320, 480, 640 ], type: [ 'avif', 'webp' ] }

[ggoodman]

I think that there seem to be two related but distinct use-cases that are floating around in this discussion. I believe that they may receive better attention if they were explicitly called out.

1. Use cases that have semantic meaning for engines at runtime (ie: media queries, workers and prefetching).
2. Use cases that relate to passing intent from code authors to the wider tooling ecosystem and that should not have semantic meaning at runtime (ie: font weights, image optimizations, etc).

In the spirit of the types-as-comments spec, perhaps it would be worthwhile to think about some explicit namespace or mechanism for code authors to pass expressive intent to the tooling ecosystem. If that was a first-class concept then we might find ourselves avoiding situations where semantic concepts like import specifiers or assertions are being used in unintended ways to achieve important and necessary goals.

[littledan]

I agree that work should go towards a general, object-based syntax rather than a single string. Many other use cases have been discussed already, in the import assertions repo, when folks were arguing that it shouldn't be limited to assertions. On the other hand, I am unconvinced that the functionality exposed in this proposal is all that high priority. Rather than as for the keyword, I would prefer something which implies that the module will be changed, e.g. with.

[littledan]

After seeing the presentation at TC39 and talking more with @guybedford , I'm convinced that this proposal meets an important use case; I've striked out part of my comment above.

While I would prefer a general syntax exposing other parameters, but there's a legitimate concern that this would be blocked in committee, as @ljharb previously did. I don't think it's worth stopping this proposal in its tracks for such a broader generalization, though the generalization would be my preferred outcome. Overall, I agree with @jridgewell 's comment that we probably made an error in import assertions using the "assert" keyword and should've been more general in the first place (however, this preference contradicts the arguments that @ljharb and @devsnek previously made, and does not have TC39 consensus; in any case, it's too late to make changes in that proposal).

If we don't go with a generalized key-value pair, I'd suggest that we use some other syntax besides as, for all the reasons that as was rejected in the import assertions case. If we're going for something specific, let's be fully specific with a keyword indicating the change in mode of importing the module. So, for example, import reflective and import asset.

For now, I'd like to focus on working out the details of this proposal, especially how it relates to module blocks, compartments, module fragments, Wasm/ESM integration, Wasm components, etc. It's good to have this syntax debate running in the background, but let's not get too bogged down on it; I am confident that we'll be able to find some syntax or other which is agreeable, and we have a lot of other details to work out.