[Master feature] TypeScript in AMP
dreamofabear opened this issue · comments
Add TypeScript support to AMP and allow new extensions to be written in TypeScript.
Motivation
Given the increasing maturity and popularity of TypeScript and potential developer productivity benefits, we'd like to experiment with TypeScript support in AMP.
Requirements
- Supports existing toolchain, particularly Closure Compiler usage
- Supports piecemeal adoption (with a rollback plan in case this I2I is rejected)
Proposal
- Experiment: Allow new extensions to be written in TypeScript, which will be transpiled to Closure-annotated JS via tsickle as a preprocess to our normal compilation pipeline.
- Gather data: Ship at least one new AMP extension written in TypeScript and collate pros/cons of development experience. Survey AMP community on TypeScript vs. JavaScript preferences.
- Convert: If gathered data is supportive, add support for incremental transpilation for remaining source and convert existing JS to TS file-by-file.
I wish I had done this July 22nd 2015 :)
Everyone, please fill out the public preliminary interest survey! 🙏
Overall:
~15% disapprove, ~20% undecided and over 60% approve.
Positive sentiment:
Static typing should yield better productivity and less buggy code.
Negative sentiment:
Concerns about TS's longevity, learning curve, and opportunity cost of code migration.
See full survey results.
This issue seems to be in Pending Triage for awhile. @danielrozenberg Please triage this to an appropriate milestone.
Just checking in; is there any update on this? Currently this is causing friction in adopting Next.js with Typescript.
This experiment hasn't been prioritized yet. Deferring to @ampproject/wg-infra for scheduling.
I'd be interested in taking a stab at Closure/Typescript interactions, what the migration process could look like, etc. Infra team has discussed using build-system as a jumping off point for the migration, since it doesn't reach the release and so would have less risk of causing a regression during migration, but would allow us to set up the main infra around building, running, and testing TS+JS
someone have news for this feature ?
There's insufficient staffing for this for the foreseeable future. Closing.
Isn't there any news about the amp on ts still?
@SiaQnbr: no news beyond what you see here
@choumx that does not seem like a decent reason for closure of a ticket, especially for something that could be automated on publish w/ something like https://github.com/urish/typewiz to at least provide something to devs.
@markhughes It seems like you have some familiarity with the relevant tooling here, so if you have an idea for a useful and non-intrusive way to address this, feel free to put a PR together and add myself/@ampproject/wg-infra to take a look at it. There's some added complication with migrating to TypeScript because of the various compilation and optimization steps that take place, which makes a transition of runtime code a bit risky, though we've had discussions about migrating some build-system code at some point. The work involved poses a not insignificant opportunity cost for the team to work on it, which I believe is part of why this feature request was closed.
My comment was not about migrating to typescript on the spot. That was about adding typescript types.
For example: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/auth0
This would allow developers using TypeScript to use the package without the package actually migrating to typescript.
@markhughes: Can you explain more? In general, developers using AMP to build websites don't directly consume AMP JS APIs. They use our Web Components instead, e.g.
<amp-list> ... </amp-list>I don't think TypeScript does html type-checking
@samouri But there is frameworks that support amp, like Nextjs:
https://nextjs.org/docs/advanced-features/amp-support/introduction
or Nuxtjs:
https://github.com/nuxt-community/amp-module
Turns out DevTools did something very similar in 2020. They also had a Closure Compiler-based JS repo and migrated to TS. They also wrote a post-hoc blog post.
I did some exploration into using TypeScript to type check the src directory to get a picture of the scope of the undertaking using this tsconfig.json
The compiler options are identical to those used in build-system and could probably be tuned to reduce the number of errors outputted, but the initial count I was presented with was 4331. While this number is large, it does seem surmountable.
This is the output of the command.
src_tsc.txt
@rileyajones See #34096 and #32693 for related work.
Have you found any benefits to TS over Closure typechecking?
Just realized this issue was already closed...but in fact, the FR is now complete as we are free to begin authoring TypeScript files.
See #37370 as the first example.