Is the trailing . in the directory name intended or a typo?

It's intended. I stole it from another test from test.dart. I'm now considering it a "convention" :)

yeah, i think a hash gets appended, so the trailing . looks cleaner

Why not git-ignore the entire directory flutter_web_generated_entrypoint/?

flutter_web_generated_entrypoint is a temp directory outside the source tree that's created then deleted (see Directory.systemTemp.createTempSync). It's only used as a temporary space to dump an entire project. The test actually only needs the index.html. It doesn't need the "counter app" Dart code.

This is a potential race condition. I would suggest adding a global counter then doing:

I'd like to understand more about the race condition. What is racing against what? I think if there is one, we should definitely handle it. However, I think we should avoid relying on user code to fix it (this code is generated once then it can be edited by the app developer), and instead fix the race in flutter.js itself.

I was thinking of the case when onEntrypointLoaded is invoked again before the previous engine initialization promise was resolved. I don't know if this case is possible or not. Maybe if the user hot-reloads multiple times in a row?

Ah, yeah, that's a legitimate concern. However, I think it should be addressed at the flutter.js level, if it isn't already. flutter.js should be aware of which phase the loading process the app is in. For example, if onEntrypointLoaded has been called, engineInitializer.initializeEngine() has been called, but the promise hasn't resolved yet, and the user hot-restarts now, then the Promise from initializeEngine should not be resolved (or perhaps it should be rejected).

OTOH, something tells me that if our initialization process is interrupted by hot restart, then all bets are off. We have so much intricate async initialization logic - root DOM nodes, fonts, CanvasKit, service worker - that there are many places that would be easily corrupted by such interruption. Perhaps what we need is some collaboration between the framework and the tool, where the tool first sends an "intent" to hot restart, and the framework sends back a signal when it's safe to do so. I'm not sure it's practical for us to try and support hot restarts at completely random points in time.

That's fair. If possible, we should at least print a warning (in flutter.js) when this race condition is detected, and ask the user to refresh the page instead.

That said, I think this race condition has existed for a while (and nobody complained) so it's probably not as important as I thought it was.