Description
In expression compilation service in DDC, inside emitFunctionIncremental, typeTable (and other internal ddc structures) are not populated currently because we don't want to call emitModule on every call to compileExpression.
DDC's expression compilation service is a bit different from the frontend_server in this case, just for initial version simplicity:
Frontend has only one incremental compiler, caches ProgramCompilers per module, and emits the whole module on build to populate these internal data structures of ddc, so we can reuse some types generated ddc already on expression compilation.
If those structures are not populated, it theoretically should only cause bigger javascript code on expression compilation, so we could choose one over another, depending what we want and can optimize. Basically it is a tradeoff between compiling more on build (rare event) vs sending more code to chrome on every expression evaluation request (happens much more often).
It appeared at the time (during the work on expression evaluation for flutter) that we should optimize for the latter, but it is totally possible that not caching ProgramCompilers is actually better in frontend_server as well - I will create a task to experiment with this in Flutter later.
Same applies to DDC expression compilation service - but, due to modular compilation, we would need to cache an incremental compiler and program compiler for each loaded module. We didn't want to introduce all the caching complexity in the first version, we need to try that out as a possible optimization later. We should be ok with just producing suboptimal js code for now.