remove namespace and use namepace import instead for tree-shaking

[ryoppippi]

As we worked on typia, I'll do this

[ryoppippi]

@samchon
After merged typia.llm.application<App>() functions in typia, I want to use this library.
However, this library has an issue of treeshaking because of use of namespace.

The reason for the emphasis on tree-shaking is that the smaller the bundle size, the better, not only for frontend but also for lambda and cloudflare workers.

That is why I'd like you to stop using namespace...

[samchon]

I know that avoiding namespace is proper for downsizing disk space. As namespace is recommended style in the C++ language due to efficient grouping and managing code, and I've developed C++ language for a long time, it's not easy to change my coding style in a day.

One thing fortunate is, current typia.llm.application<App>() is importing LlmTypeChecker and LlmSeparator modules, and their disk size is very small. Also, as they are strongly dependent to each other, no significant merit by tree shaking would be. The other modules like HttpLlm and HttpMigration have the same story.

However, I also considering about the OpenApi module. People who use @samchon/openapi may utilize OpenApi.convert() function a lot, but OpenApi.downgrade() may not. So tree-shaking by escaping namespace may read significant disk space downsizing. However, I don't have proper solution to here yet.

In this v1 major update, I one time considered to escape namespaces and keeping ESM tree shaking by entirely refactoring the @samchon/openapi, however, I cound't do it due to below reason. It was possible to entirely break the namespace structure in the typia (maybe v7 major update), but could not in @samchon/openapi. I hope to keep current namespace structure at least for the interface types.

In the namespace. Is it possible to add utility functions in the namespace with keeping ESM tree-shaking?

If you have any good idea, please help me.

• Hope to gather same categorized interfaces into a namespace.
  • Good for reading and comparing
  • When learning OpenAPI specification, it needs to be read entirely
• Considering not to using namespace, I have to define individual interface files, and re-export them. However, as there're many OpenAPI versions in this @samchon/openapi library, the re-exporting interface types may lead users to confusing. At least, I hope to keep current namespace defined interface types.
  • Confusing
    • IOpenApiOperation (@samchon/openapi emended v3.1 spec)
    • IOpenApiV3_1IOperation
    • IOpenApiV3_IOperation
    • IOpenApiDocument
    • IOpenApiV3_0JsonSchema
  • Clear
    • OpenApi.IDocument
    • OpenApiV3.IJsonSchema
• In the namespace, is it possible to add convert() and downgrade() functions with keeping ESM tree-shaking?

[ryoppippi]

@samchon
Thank you for your reply as always.

I think using export field is one solution

for example

import { convert } from '@samchon/openai/i-open-api-v31'

like so