Closed Denz1994 closed 3 years ago
Here's a rough plan of attack:
tsploration
branch in dotindex.d.ts
(dot doesn't need to know about TS)My biggest question/concern is how we're handling module dependencies. If I recall correctly, this was a major sticking point during the ES6 discussion regarding import
and export
statements as well as properly accessing common code from a sim/repo .ts file (plenty of info about this out on the internets and most make it seem like incremental transition is quite possible).
My biggest question/concern is how we're handling module dependencies.
We would have the same barrier to using Flow for types.
Is this something we want to continue to pursue?
Some thoughts on the topic, not necessarily connected, complete or in order of importance:
@jonathanolson mentioned another concern in the 6/6/2019 dev meeting:
This was discussed in today's dev meeting, we did a poll, and ultimately decided to look at this and related language improvements at some point in the future.
Gave myself a calendar reminder for Nov 4 2019. Unassigning for now
I followed these instructions to tell WebStorm to check JS code using the Typescript type checker: https://blog.jetbrains.com/webstorm/2019/09/using-typescript-to-check-your-javascript-code/
The results looked something like this for main/gas-properties/js/diffusion/view/DiffusionSettingsNode.js
To elaborate on the previous comment, TypeScript has a feature to type check JS files described here: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html
It may be a way for us to leverage typescript type checking and our existing JSDoc without switching languages.
I saw this article about why one company decided to move from Typescript to Javascript: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcr1aFbQ*c7R6Bt9IKDZaBJdD7_Ie0g
Some highlights:
We discussed typescript again today in the context of https://github.com/phetsims/axon/issues/343. Would be nice to have interfaces and not rely on TypeDef/documentation.
Typescript also came up in the context of https://github.com/phetsims/phet-info/issues/143 where we discussed mixins and traits.
I reaffirmed that it is very efficient to run code in the browser without a compile step. And that the widespread usage of JS is appealing. Would TS make it difficult or impossible to optimize certain code bottlenecks? How much effort would we have to invest to port everything enough to get the benefits of TS?
How would typescript deal with our established options pattern? See https://rclayton.silvrback.com/easy-class-api-options-with-typescript-and-joi
We keep identifying problem after problem that could potentially be solved by typescript. I'd like to open this for a short developer meeting conversation to ask the following questions:
(1) Can we rule it out as a possibility? For instance, here are some potentially blocking technical problems:
or any other potentially blocking problem. I suspect that many practical problems could be solved, worked around or avoided, but I recommend a developer meeting to gauge developer interest and preference around practical problems like:
(2) If we cannot rule it out as a possibility, let's discuss a potential Q3 investigation and Q4 migration. If we want to move forward, this issue would become an epic "investigation" issue and another issue would be for the migration. I would like to be involved with both the investigation and migration if we agree to proceed.
Quick list of what we stand to benefit:
Notes for investigation:
I wanted to understand better how typescript would deal with options, and I tried creating an example project.
type StormOptions = {
darkSkies: boolean,
prettyWindy: boolean
};
type TornadoOptions = {
canLiftAHouse: boolean,
name: string
} & StormOptions;
When I pressed for code completion in the options, typescript mentioned all of the possible allowed keys and where they were defined.
If I try providing an option that doesn’t exist, typescript gives me a heads-up:
I am surprised and interested that types can be applied to the options and not just the class types. I also tested that this allows us to rename key names across occurrences and it seemed to work great.
Patch with this example:
That's impressive!
After the above commit, example-sim is written in typescript (in a branch). The migration took around an hour, and that includes the time to add some auxiliary types, which I'll put in a patch below:
The main is launched via: http://localhost/main/chipper/runts.html?sim=example-sim
runts.html is in chipper:
and here's tsconfig.json:
And some ambient types:
I've kept most of this out of master to avoid unintentionally disrupting other developers' environments. Webstorm prefers to navigate to d.ts files if they exist.
Notes from discussion with @jonathanolson:
Really excited, seems promising--typescript has many features that we have been creating on our own.
Questions about Features:
Requires Investigation:
Today at dev meeting, I demonstrated the following features using example-sim's typescript branch:
The development team generally seemed interested and excited about these features. We also briefly discussed:
JB: Traits and mixins JO: Generic type support, mixins MK: Interfaces
MK: How to deal with shared files between chipper and perennial, like SimVersion.
SR: Right now that is a preload, but would work better as a module.
JB: How fast is the turnaround time when compiling a larger simulation? SR: I tried building a compilation unit that included all sims, and it worked OK and quickly, but slowed down if changing the interface of a central file like Node. Some ideas for improving that are using typescript project references to break it down into smaller units, or using a pure transpile step for quick iteration.
JO: Make sure it works well with the build process, maintenance releases, etc. So there will be a transition period.
MK: How could we revise the string plugin? SR: JSON files can be imported natively by typescript.
MK: Is typescript well maintained? How does the transpiled output look?
MK: Should we have something like wilder, but for typescript. Try the fun features in a single place.
Designers and others may have local copies checked out, which would need a build step. This will also be a problem for CT, phet-test, etc.
SR: I'll continue to investigate at low priority in the background. When I have answers to more of these foundational questions, then we can come up with a plan and proposal to discuss with Kathy.
SR: I'll continue to investigate at low priority in the background. When I have answers to more of these foundational questions, then we can come up with a plan and proposal to discuss with Kathy.
Maybe a better plan would be to discuss with Kathy sooner rather than later, and elevate investigations to medium priority--something that can be done when my Q2 goals are complete or awaiting feedback.
Re-labeling for dev meeting to touch base and confirm how to proceed.
From 5/6/21 dev meeting:
SR: How do devs feel about moving forward with investigations at medium priority?
All devs are on board with proceeding! (UPDATE from @samreid: note that @pixelzoom and @jbphet are absent today)
MP: what scope would this cover?
SR: Level 1: sim-specific code Level 2: sim common code Level 3: node code Level 4: PhET-iO wrappers
I'm really excited about this, and look forward to future investigation. I feel like it is unlikely that any con we find outweighs all the potential benefits.
I also noticed that we can use TypeScript in node pretty easily without a compile step, as we can treat it as its own language. This is exciting! See https://nodejs.dev/learn/nodejs-with-typescript
@samreid said:
Maybe a better plan would be to discuss with Kathy sooner rather than later, and elevate investigations to medium priority--something that can be done when my Q2 goals are complete or awaiting feedback.
I think it's best to discuss with project management sooner. From what I've heard, there will be long-term benefits. But there will also be significant short-term costs (learning curve, converting code, establishing new patterns, build tools, etc.) that will need to be balanced with other project goals. Without incurring some of the short-term costs, I don't have the experience to quantify the costs or benefits.
All devs are on board with proceeding! (UPDATE from @samreid: note that @pixelzoom and @jbphet are absent today)
I'll be happy to use TypeScript, if that's what PhET decides.
Today, typescript came up while @zepumph and I were discussing https://github.com/phetsims/phet-io/issues/1763 with @kathy-phet. We gave a brief description and overview of the language, described how it has been proposed as a solution to numerous different PhET problems, and how other companies such as Slack, Airbnb and Google have reported significant advantages when they converted their codebases (referring to the "Migration Stories" listed on https://www.typescriptlang.org/). I reported sharing initial ideas with the development team and that the dev team said it sounds promising and recommends further investigation. @kathy-phet agreed it would be good to move forward with the investigation, starting after Q2 goals are winding down. I added a new row to the PhET Project Overview document.
From discussion with @pixelzoom:
CM: Can webstorm do the compilation for us? Instead of tsc --watch.
CM: A colleague pointed out that in the debugger, you can end up in the additional compiled code, not your code. Got around that via breakpoint in his code. Going from "parallel universe" back to your code as you debug.
CM: 3rd parties will need to know typescript. That may be one more entry barrier for 3rd parties. SR: On the other hand, this could help newcomers navigate and understand our code. CM: Hiring a new developer, typescript experience wouldn't be essential. For example, [...] got up to speed quickly without much (any?) js experience. So TS may not be too much of a barrier. I'd rather have a good learner than someone with a lot of typescript experience but keeps making the same mistakes over and over. TS is lower on the list of desirable attributes for a new hire.
SR: We could follow this order for migration:
CM: Should this be focused for internal code? Public code APIs would remain in JS.
SR: How will we estimate the effort to port everything? Common code? Sims? CM: If it really has advantages, we would probably want to convert sooner rather than later. I prefer being proactive about this kind of thing. If it seems like a win in one sim... But not wanting to change working code.
CM: Before we start coding, determine other conventions we should change, etc. Should we still use JSDoc the same way? Like function parameters, etc. ColorDef => interface or abstract class Mixins Enum. Do we want enum or type = 'a' | 'b'. Could we get rid of EnumerationIO if we just use strings? So studio could show radio buttons and not a text field. Make sure we aren't missing something that would sabotage phet-io.
CM: Webstorm doesn't know that NumberProperty is Property
SR: How long will we be happy using both TS/JS in our codebase?
SR: Are there any milestones or sweet spots that would be good to hit for migration? Before a new hire? CM: If that's within 6 months, JS will probably be very important. Maybe discuss whether they are willing to typescript. Before SR starts E&E CM: It's nice to do the investigation with something concrete. Make sure the sim also gets phet-io instrumentation to make sure it's a good fit.
CM: Fourier is supposed to be done by Sept. Feature complete end of June. I wouldn't convert it before publication. Other features were not scheduled, but creeping in. May have a new sim in Aug/Sept. SR: Maybe only use typescript on sims until fourier is published, so it isn't destabilized? CM: As we get closer to feature complete or QA testing, sooner would be better.
CM: I don't think I need to be sold on the idea that TS is a better language. There will be an initial learning curve, but I expect it will pay dividends down the road.
Oops
I didn't know if we were going to have to totally convert away from eslint, it looks like there is a chance we wouldn't necessarily have to (https://khalilstemmler.com/blogs/typescript/eslint-for-typescript/), but perhaps tslint will make more sense to use because we will be writing in a different language.
Here's a patch that adds 2 modes of typescript builds to chipper:
(1) grunt tsc
runs the typescript compiler on a project and outputs the result to chipper/dist. The HTML file points to chipper/dist. This would be used in place of "unbuilt" for fast iteration. Using package.json would enforce the same compiler verison. We would need this to run on phettest, bayes, fresh checkouts, etc. This is also the build that IDEs such as WebStorm would use, since it integrates with the tsconfig.json. May be able to make iteration even faster with a transpile-only mode, but it is already kind of fast (I split it into 2 modules).
(2) grunt
supports typescript via the ts-loader
. I tested by converting a few example-sim files to typescript. It works OK but leaves some things to be desired.
optimization.emitOnErrors: true
might work?grunt tsc
as well.
From Dev Meeting: 02/14/19
While reviewing https://github.com/phetsims/dot/issues/84, it became apparent that the loosely typed nature of javascript makes refactors more difficult, as seen by the commits made by @samreid here. @mbarlow12 was advocating that Typescript may be a useful alternative.
Some benefits include typechecking, target directories for compiling, and a javascript in and out approach.
Potentially,
DOT
can be prototyped for experimentation. Assigning to @mbarlow12 for follow up.