Introduce import.meta.glob

[ef4]

Rendered

[NullVoxPopuli]

this would immensely help the migration path to ember-mirage

cc @bgantzler / @cah-brian-gantzler

[cah-brian-gantzler]

Not only the migration path, but if its an approved way to discover files, could put the auto import of all the mirage files back in instead of you having to import them individually and create the hash

[NullVoxPopuli]

I'm in favor of not supporting this behavior

[NullVoxPopuli]

docs: https://vitejs.dev/guide/features.html#glob-import

[NullVoxPopuli]

I think I worked this out between the two RFCs, but wanted to keep my thought process here in case others have the same/similar thoughts

---

I've used eager in my spikes of wiring up Qunit in Vite.

since we're using native modules though, and native modules support top-level await, we could effectively re-implement the behavior, if anyone needs(?) this way:

import * as QUnit from 'qunit';
import { setup } from 'qunit-dom';

setup(QUnit.assert);

const moduleRequests = import.meta.glob('./**/*test.{js,ts}');

// loads all the test files, which are then registered with QUnit
await Promise.all(Object.values(moduleRequests).map(loader => loader()));

Though, this requires that our distribution format is ESM, yeah? like, we couldn't keep shipping AMD if we wanted to do something like this.
(

I think that's the point of the other RFC tho?: #938

in particular,

• we cannot implement other standard ECMA features like top-level await until these incompatible APIs are gone (consider: how is require() supposed to deal with discovering a transitive dependency that contains top-level await?)

)

[ef4]

I don't want to create a hard dependency between this change and top-level await, so I don't think we should say that's the upgrade path. We want to implement import.meta.glob in classic builds too, where we may never support top-level await.

But we don't need top-level await to achieve a compatible way to wire up tests. Both because (1) Embroider already synthesizes a test entrypoint that works in vite, and (2) even if you wanted to redo that to use import.meta.glob, it's up to us when to start the qunit tests.

QUnit.config.autostart = false;
Promise.all(Object.values(moduleRequests).map(loader => loader())).then(() => QUnit.start());

I do think your question points toward further simplifications of our programming model though. It would be possible to codify the "what is an ember app and how do you boot it" in terms of import.meta.glob. Today the conventions are implicit and Embroider and classic both try to implement them by having opinions about what files to stitch together into the entrypoint of an application. But we could retcon that in terms of import.meta.glob and make it visible to users.

This would be for a v2 app RFC and/or Polaris Routing RFC. But you can imagine how it would work:

const MyRouter = Router.map(import.meta.glob("./routes/**/*.ts", { ... })

The examples @wycats showed at EmberConf were similar but they said Router.map(import.meta, { ... }), and I've confirmed that's not really going to work in existing build tools like Vite. They have the static requirement on import.meta.glob that I've encoded in this RFC. Passing the output of import.meta.glob though would work, and would make it clear which "entry points" you're telling the app to work with.

[ro0gr]

seems Record value should be a function

(pattern: string): Record<string, () => Promise<unknown>>

[ef4]

This is correct, thanks, that's just a bug in my text.

[ef4]

Moved to exploring in RFC review meeting.

[ef4]

Status here: I have some minor fixes to do and I want to propose adding eager: true before saying this is ready to consider for advancement.

[ef4]

I added eager mode and this is now ready for a second look and I hope we can move it to accepted on the next RFC review iteration.

[achambers]

We're fine with this one - from the morning RFC Review ;)

[NullVoxPopuli]

Plugin for adding support to import.meta.glob to non-embroider apps:

• https://github.com/NullVoxPopuli/ember-classic-import-meta-glob