Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC/Proposal]: Add types for modules #326

Open
RichDom2185 opened this issue Sep 23, 2024 · 2 comments
Open

[RFC/Proposal]: Add types for modules #326

RichDom2185 opened this issue Sep 23, 2024 · 2 comments
Assignees

Comments

@RichDom2185
Copy link
Member

Background

With Source Typed, it is now possible to teach strong typing at an introductory level. Naturally, it extends to modules, something that students interact with a lot in Source Academy.

Possible Considerations

The "exposed" type should be separate from the actual implemented type

To enforce abstraction principles. For example, while runes are by no means a primitive type in its implementation (using higher order functions, etc.), we should treat them as such.

Ideally, types should be inlined

https://github.com/source-academy/js-slang/pull/1467/files#diff-2e2aa2db6619eec1be92cd4c227f51bafd0c3e8a0ba28a58c105e5e08944ec5d gave a proposed method of defining types for modules. However, not only are they located in a separate file, they are located in an entirely different repository (and NPM package). This makes keeping consistent type definitions difficult.

Ideally, we should be able to define the types of members we want to type, as well as "type aliases", inline, as much as possible.

Proposal

We propose writing a custom esbuild plugin to handle this use-case. It will be transparent, requiring minimal-if-no changes to existing modules to leave them untyped.

Using decorators attached to each name we want to type, the hope is we can generate the metadata/type definitions not unlike the one above, during build/bundle time, based on the values supplied in the decorator.

Feasiblity

Will need to investigate.

See also

source-academy/js-slang#1400 (and related hyperlinks within)

@leeyi45
Copy link
Contributor

leeyi45 commented Oct 25, 2024

Currently there's a bunch of typing information provided by typedoc through the JSONs. Is that sufficient? Should we look into using typescript declaration files?

I'm not sure if esbuild is capable of/the appropriate tool for doing this because it was designed to ignore type information.

@RichDom2185
Copy link
Member Author

Currently there's a bunch of typing information provided by typedoc through the JSONs. Is that sufficient? Should we look into using typescript declaration files?

I'm not sure if esbuild is capable of/the appropriate tool for doing this because it was designed to ignore type information.

@tohlh is trying to work on it for his FYP. Type information is ignored by ESBuild yes, but we don't want the actual types of the implementation anyway (i.e. to students, heart is a primitive of type <Rune>, instead of a function).

Last time I followed up, I think we just create a context where we can declare inline what types we want the functions to have, and ESBuild output a separate object that can be read as the "type declaration" for these bundles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants