Merge Ezno runtime definitions with existing TS definition files

[kaleidawave]

Currently the checker is built around definitions from this file

https://github.com/kaleidawave/ezno/blob/main/checker/definitions/overrides.d.ts

To support more of the runtime (as highlighted in #118), the checker should be able to use definitions from the TypeScript repository (such as es5.d.ts) to provide the same type coverage. As can be seen in overrides.d.ts, Ezno has some extended definitions to provide better information to the checker. What should be done is to create a tool (code mod / code modification) (similar to code_blocks_to_script.rs that parses es5.d.ts but selectively overwrites with definitions in overrides.d.ts to produce a final definition file build.

Warning

#120 (increasing the count of types and layout) is really needed to support the scale of es5.d.ts

[kaleidawave]

Some thinking on es5.d.ts

Also I don't quite know the status of how much of es5.d.ts Ezno currently supports. For example the features:

• rest parameters
• optional parameters (I think but, no tests?)
• overloading (TODO write up issue)
• Mapped types (TODO issues for the last two maybe)
  • Record
  • Pick
  • Omit
• readonly properties
• Symbols

Taking a flick through some things

• Not all overloading needs to be considered
• Some helpers like Awaited might not be needed initially (or implemented in other ways)
• what to do for intristic types
• *X* and *X*Constructor types can be merged (as the definitions now use classes)
• Things like Math need @Constant decorators on most methods (but Math.random() needs @InputOutput
• Console needs @InputOutput on most methods

[CharlesTaylor7]

What does the @Constant decorator mean?
Does it mean that the function can be safely run at compile time?

[kaleidawave]

@Constant marks a function or method as having its effect as FunctionEffect::Constant which yes principally means its return type is fixed and can be calculated at compile time IF its inputs are literals. This calculating is done in the checker/src/features/constant_functions.rs file.

For example here Math.sqrt is a function with constant effects under identifier sqrt

ezno/checker/definitions/overrides.d.ts

Lines 129 to 130 in 24e35b9

	@Constant
	static sqrt(x: number): number;

and if its input are known and literal (for example 16), then it can be calculated in Rust

ezno/checker/src/features/constant_functions.rs

Line 83 in 24e35b9

"sqrt" => num.sqrt(),

which is how you get the errors here.

It is a slightly bit gimmicky, it can catch against some always true cases but only when you are dealing with constants. It is still WIP, some cases are changing, it is slightly abused for the print_type and other helper functions for development. I should write up some more documentation for it and its other kinds!!

(If there is no identifier passed to the decorator it just sets the constant identifier as the name of the function method it is under)

[notramo]

@kaleidawave, why is a code mod required? Why not simply parse the ES5 definitions first, then the custom definitions overwriting clashing names in memory in a similar fashion as e.g. src/app.d.ts overwrites the built-in types of the framework in a SvelteKit project?

[kaleidawave]

Hmm that is an option, will consider! With the binary definition file system for the base definitions the duplicate work will only be at build time.

[kaleidawave]

I will have to account for slight differences in definitions. For example in es5.d.ts they create two interfaces for a class and use a var to define the class type

interface Array<T> { 
	// ...
	push();
}
interface ArrayConstructor { 
	// ...
	isArray();
	readonly prototype: Array<any>
}

declare var Array: ArrayConstructor;

In Ezno I have been typing it with

class Array<T> {
	// ...
	push()

	static isArray() ...
}