Type only imports for Luau

[VegetationBush]

Rendered

Implements a type-only import for Luau similar to that of TypeScript. This feature aims to introduce type extraction without runtime imports.

[Bottersnike]

Potentially worth considering #103 as an alternative. 103 adds a special import keyword (rather than continuing to use require) and as part of that it has support for explicit type imports

[VegetationBush]

While #103 is similar, I personally wouldn't consider it as an alternative.

It seems like #103 is simply syntactic sugar for importing values or types, which to my understanding does not solve the runtime dependency problem. I might be wrong, though, but it seems like import x, y, z from "path" still creates a dependency with "path".

Even if we assume that importing strictly with types do not generate runtime dependencies:

import type apple, type banana from "Fruits" --> type only importing; do not generate a dependency!

I personally dislike behavioral ambiguity when it comes to features. For instance:

import fruitTable, type apple, type banana from "Fruits" --> myvalue1 is a value; runtime dependency generated!

... not to mention that the runtime dependency is very difficult to determine at a glance.

I'd much prefer splitting type retrieving behavior with a different keyword that does one thing consistently, than add a feature with multiple behaviors that can easily be misinterpreted.

[jackdotink]

Importing types without also adding a runtime dependency is next to useless because circular type imports is not a feature that luau supports, and is not a feature that luau will support.

The proposed syntax is currently ambiguous:

type foo = require
(expr):something()

[MagmaBurnsV]

I think trying to solve cyclic dependency issues in a scripting language with dynamic imports is a fool's errand, disregarding how feasible this even is.

Cyclic dependencies at runtime aren't allowed, and pretty much all cases for cyclic dependencies also require the runtime factor, so I can't imagine type-only cyclic dependencies being all the common to justify supporting. Even if it's useful in certain scenarios, I would consider it bad practice and prefer the alternative of using a third module.

[znotfireman]

typeget(x) syntax is ambiguous. typeget is also not an ideal name.

I think it'll be better to introduce this as a type function. Maybe:

type function require(path: type, export: type, ...: type)
type Mechanic<T> = require<"@libs/Mechanic", "Mechanic", T>

To import the Mechanic<T> type from the module at "@libs/Mechanic". Worth considering how generics from other modules play here.