[TS] Generated single entry point is not API compatible with flatbuffers 1.x

[bjornharrtell]

I realize now #6673 was misguided because it disregards namespaces and hacks around that by renaming symbols. That creates an entry point with potentially far too many symbols and unexpected symbol renames.

What would be the correct design would be to generate an entry point per namespace and reexport from the parent. That would be equivalent to the nested namespaces that was handled as namespace objects in 1.x code generation and could be used to bundle up an 1.x API compatible single file code generation file.

[dbaileychess]

So one important thing to consider is that build systems like bazel (and Blaze within Google) require that all generated files be known and explicitly stated in the build rules. So when we have --ts options spit out multiple files given a single input .fbs, it is hard to write the build rules for that. This is especially true for "large" schema that import many other schema, it becomes really challenging listing out all the expected generated files.

[dbaileychess]

See "outs" at https://bazel.build/reference/be/general#genrule_args. We wrap the flatc in a genrule and generally expect a 1:1 input to output.

So this is why having a single file makes it easy to work with.

[bjornharrtell]

@dbaileychess you are misunderstanding. This issue is not about how or why a single file build is useful. It's about the entry point that you can use to create single file build. It does not produce something that is API compatible with what you got with flatbuffers 1.x and this issue and suggested solution is how to fix that.

I'll rephrase the subject of this issue.

[github-actions]

This issue is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.