Skip to content

LuaLib Refactor #653

@ark120202

Description

@ark120202

Transformation changes

The first part is making builtins transformation more generic. Currently all helpers are used imperatively. A declarative solution should make code cleaner and allow some features that currently can't be implemented:

  • Non-call references ([1.5, 2.5].map(Math.floor))
  • Expose static information about supported builtins (for language service plugin)
  • Some sort of plugin system (since we can't really support polyfilling). It probably should use the same API as Pluggable transformer design #615.

Importing changes

The second part is helper files location.

First thing, I think we should completely drop inlining. TSTL helpers have a completely different use case compared to TS ones - they are a lot bigger and used more commonly (in TS they are used only for syntactic transforms, not for builtins). They are actually more similar to polyfills, which aren't inlined by any popular transpiler. In addition they can cause some huge issues due to having different references. The only use case for inlining is environments without module support, which should be covered by bundling.

Requirements:

  1. Using one helper shouldn't load all of them
  2. Helpers should be shared between modules when possible
  3. Exposing global types (Explore using custom types instead of tuple and iterator decorators #580)
  4. Exposing importable helpers (as a replacement for directives like forRange and luaTable)
  5. Modules (New module resolution and Compilation structure #432) compiled with older version should continue working when used in application using newer one (even across major releases)

Option 1

Keep helpers where they are, import them with absolute requires.

  • 4 becomes harder: the only way would be rewriting these imports, which also would cause issues with versioning.
  • To do 5 we should never change helper signatures or remove them, and instead always create new helpers with different names.

Option 2

Distribute helpers as a separate package, import them as modules.

  • Depends on New module resolution and Compilation structure #432, which, in turn, depends on this issue.
  • Repository structure would have to become a bit more complex (monorepo).
  • We'll be able to depend on modules in helpers, which could be useful for some huge features (promises, console-like formatting).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions