Help me to implement https://github.com/tc39/proposal-type-annotations

[frank-dspeed]

i would love to create a fork and maybe even make a PR if you want to also adopt that and it algins also with your goals.

https://github.com/tc39/proposal-type-annotations i want to implement that porposal on top of graaljs so that typescript would work untranspiled directly inside graaljs

Questions

as this needs to parse general all function arrguments and all object assignments what would be the related files should i create new files or should i implement that in the current set of files?

my guessed entrypoint is: https://github.com/oracle/graaljs/blob/master/graal-js/src/com.oracle.truffle.js.parser/src/com/oracle/truffle/js/parser/JSParser.java is that the full scope?

[oubidar-Abderrahim]

Hi, maybe @iamstolis could assist on this?

[iamstolis]

The mentioned proposal is in a very early stage (Stage 1). The goal of Stage 1 is to examine the problem and possible solutions. Nothing is fixed at this stage. It may even happen that there is no specification at all. We usually implement proposals that reach Stage 3. This particular proposal contains some tentative grammar already, but considering how much push-back the current form of the proposal received on the last standardization meeting, it is unlikely that the grammar would not be changed significantly when/if the proposal moves into higher stages. In other words, it is too early to implement this proposal.

[frank-dspeed]

@iamstolis that is correct thats why i would even implement it my self in a fork i see clear that it solves a lot of issues to simple handle type annotations as comments and it saves me from transpiling. It directly Enables loading .ts files.

i also think it is relativ easy to implement and would teach me some good stuff in general out of my mind it would only mean to adjust the Parser so it ignores the annotations in a later version it could create comment nodes out of it.

you are correct that there will change stuff but it will happen anyway for my Own lang which is designed as superset of JS it is already needed.

https://babeljs.io/docs/en/babel-plugin-transform-typescript shows most of the current issues but i also investigate on the Typescript Project it self to get it all algined

at chromium we already also implemented and tested it and took the learnings a graaljs fork with that proposal would even speed up the proposal to land as it would help me to demo and define the edgecases with realworld code.

• proposal strong mode https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp49nDQMZ1y7fwf5YjaI4/view
• STRONG MODE FEATURES IMPLEMENTED IN V8.4.9 https://groups.google.com/g/strengthen-js/c/ojj3TDxbHpQ/m/5ENNAiUzEgAJ

Conclusion

A type system will happen we push that from multiple sides graaljs could be a good foundation for real live experiments that will lead to a faster proposal stage 2.

it could also be a good foundation to implement typescript it self in graaljs

[woess]

as this needs to parse general all function arrguments and all object assignments what would be the related files should i create new files or should i implement that in the current set of files?

You're welcome to experiment with the Parser (and related classes). Probably easiest to modify it directly, with the type annotation specific parts guarded by a feature flag.

[frank-dspeed]

@woess how would i implement or pass such a feature flag on what level should i do that. I did never release a Java Project with any flags i avoid such stuff i also did google about the term and i could not find anything i guess you mean a compiler flag?

so that it does not get compiled or do you mean something like a runtime flag on context create if so where do such flags get implemented?

[woess]

@frank-dspeed Yes, I mean a context option. Those are defined in the class JSContextOptions and JSParserOptions. You can follow the examples there.

[lemanschik]

Landed in NodeJS

• module: add --experimental-strip-types nodejs/node#53725

[caoccao]

You might want to read my blog post Run TypeScript Directly in Java. In brief, swc4j can help transpile TypeScript to JavaScript with exactly the same logic that Deno uses.

[lemanschik]

@caoccao sure it can do that i also got success simple transpiling tsc and replacing the filesystem with the graaljs one

[lemanschik]

@caoccao but the final goal would be that the parser strips the type without any other additions.

[caoccao]

@caoccao but the final goal would be that the parser strips the type without any other additions.

I've been reviewing Deno, Swc source code for years, and I'm the maintainer of swc4j. I'm afraid that's not an easy work if you want to start from scratch. Node.js offloading the work to Swc is a sign. In order to identify what is a valid TS type annotation, there will be tens of various TS types to be well implemented in the parser. That's also one of the reasons I worked out swc4j so that there's single source of truth (Swc) that Deno, Node.js and swc4j all follows.

Here is a list of level 1 TS types to parse for your reference.

• TsArrayType
• TsConditionalType
• TsFnOrConstructorType
• TsImportType
• TsIndexedAccessType
• TsInferType
• TsKeywordType
• TsLitType
• TsMappedType
• TsOptionalType
• TsParenthesizedType
• TsRestType
• TsThisType
• TsTupleType
• TsTypeLit
• TsTypeOperator
• TsTypePredicate
• TsTypeQuery
• TsTypeRef
• TsUnionOrIntersectionType

[lemanschik]

@caoccao i am at present trying to create a llm based compiler and got good results i guess we can soon throw all the languages away at last thats my final goal

[caoccao]

Good luck!