which otherwise lacks the information to set this field

Why is this the case now but not before this PR?

Because the module indicator now depends on the compiler options the source file was created with, which the source file retains no direct reference to, and small incremental edits (the kind that don't do a full source file rebuild) don't pass in full options, either, they just reuse the old source file's data - so we have to keep the callback around to reuse in that incremental scenario.

Hm, I forgot that parsing in general, much less incremental parsing, doesn’t have access to CompilerOptions; only the (previously very small) subset of them that it needs. I’m a little worried that this will become a footgun whereby we or other API consumers will accidentally close over and retain something they shouldn’t in this function (it you haven’t seen the implementation, you don’t know a reference to it is stored on the SourceFile—the property is even erased from the public API!). What ifCreateSourceFileOptions took themoduleDetection,module, andtarget from CompilerOptions and stored those, such that the function currently returned bygetSetExternalModuleIndicator would have everything it needs to run on the SourceFile after creation? It would be more properties to store, but more straightforward. It took me a minute to understand the purpose of this indirection.

Hm, while that would be enough for recalculating the correct closure, it doesn't do much to help theimpliedNodeFormat field calculation, which needs extensive host availability anyway. I'm disinclined to make these look likeCompilerOptions because of that - if you just passed in compiler options, you'd be broken in any nodenext type scenarios.

impliedNodeFormat now gets passed intocreateSourceFile (and I wasn’t proposing removing that, for the reason you mentioned), and I was assuming it can’t change duringupdateSourceFile (incremental parsing)—is that right? If so, then incremental parsing doesn’t need to worry aboutimpliedNodeFormat.

should there be? (there might not be any NodeFlags left in any case)

This bails on the first JSX tag you find in a JSX tag, which is usually almost instantly, so.... probably not? Still, I thinknode.transformFlags & TransformFlags.ContainsJsx probably already tracks the same thing and post-node-factory change should always be set, so... I'll try that out for narrowing the search.