Experimenting with JavaScript type safety in mozilla-central

[Dave Townsend]

JavaScript powers a lot of Firefox but unlike the other languages that ship
code in our product JavaScript uses a dynamic type system. Types for
variables are decided at execution time and can change as new values are
assigned to them. This leaves you open to accidentally passing the wrong
kind of data around your code. Easy to do when APIs are changed on the
other side of the tree.

Flow and Typescript have gained prominence recently as tools that add
static types on top of JavaScript giving you a build time check (note: no
runtime checks) to see if the types you’re using look correct. A number of
us have used these tools successfully in side projects and want to see if
using a tool like this would be beneficial in Firefox.

A first experiment towards understanding this has just landed (
https://hg.mozilla.org/integration/autoland/rev/1dd081553a3a). Specifically
Greg Tatum has added TypeScript <https://www.typescriptlang.org/> type
annotations and configuration to the JavaScript code in the
devtools/client/performance-new directory.

The mode of TypeScript we’re testing involves annotating types with
comments, the JavaScript code itself is just normal JavaScript. All of the
TypeScript bits live in comments so there is no build step and we’re also
not adding any automated tests to verify the types in CI for this
experiment.

For the time being the perf tools team will just be checking the types
locally before committing. This will give us an idea of the benefits on
real in-tree code without any impact outside of the team.

If you have any concerns with this or want to know more please let us know.


Dave

[Mike Conley]

This is a great thing to start looking into. I myself have definitely been
burned in the past because something unexpected got coerced into something
equally unexpected, resulting in behaviour that is without-a-doubt
unexpected.

So thanks to the folks getting this off the ground!

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Greg Tatum]

I was getting ready to write up some updates, but was waiting for some of
my most recent type work to land. I'll go ahead since there is interest. So
far the experience of working in devtools/client/performance-new [0] has
been really positive. It's a bit challenging getting the TypeScript module
system to work with our variants of loaders, but I've made progress to get
it working in at least one our smaller folder. It will take a broader
effort to really teach TypeScript about Gecko, but it seems doable, and
seems like something that could be done as an incremental improvement.

The profiler front-end (which is on GitHub, and is profiler.firefox.com)
uses a different type system (Flow), and we've really leaned in hard to it
to trust that our code is working as expected using the type system. We've
been using Flow there for nearly 3 years. So far, TypeScript seems to be
able to do most all of the things that we've been relying on in
profiler.firefox.com, but inside of Gecko. I'm feeling a lot more confident
making changes to the code, and being able to understand the interfaces I'm
consuming while writing and reading code. In the next month or two we will
be heavily refactoring the profiler popup code, so hopefully the types will
help with that work, and let us move quicker.

Here are things I've gotten types working with:

* Profiler popup panel
* React Component (landing now)
* A frame script, and its environment
* JSM files
* Test files (only locally so far)
* DevTools module loading system
* Somewhat hacky with Chrome.import, and Cc["module"] style imports.

So far I'm treating the rest of Gecko like it's a foreign world that I
can't touch. However, it should be possible to make the types work with
more "modules" in the rest of the codebase. For instance, I could see
teaching IDL files to spit out TypeScript declaration files and automating
some of this process.

As for the test runner, right now it's a simple command to run from the
terminal [1], but we could hook it into a mach command, and integrate it
with our try services. I did an experiment earlier to demonstrate that this
was feasible [2]. Right now, I'm mostly relying on in-editor hints, as VS
Code loads the config files by default, and provides in-editor hints [3]

I know from the folks talking about types earlier, we're definitely
interested in other teams adopting some TypeScript comments in their own
areas of the codebase, so we can gather more feedback. If anyone is
interested in experimenting, I'd be happy to help guide some initial setup.

Next, I believe we are planning on continuing to experiment with real code
in tree, and evaluate what the next steps look like, e.g. official mach
runners, and try server integration.

[0]:
https://searchfox.org/mozilla-central/source/devtools/client/performance-new
[1]:
https://github.com/mozilla/gecko-dev/blob/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/client/performance-new/typescript.md
[2]:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=201f27967c8c6f26c6a4430fb1307478769762f7&searchStr=devtools&selectedJob=266879166
[3]: https://giphy.com/gifs/VJkwziVsCYGvOGNsv0







On Tue, Nov 12, 2019 at 2:13 PM Andreas Tolfsen <a...@sny.no> wrote:

> +gtatum
>
> Also sprach Dave Townsend:

>
> > A first experiment towards understanding this has just landed (
> > https://hg.mozilla.org/integration/autoland/rev/1dd081553a3a).
> Specifically
> > Greg Tatum has added TypeScript <https://www.typescriptlang.org/> type
> > annotations and configuration to the JavaScript code in the
> > devtools/client/performance-new directory.
>

> As mconley said, this really is great work! Any step we can take
> to make using JavaScript safer should be applauded.
>
> We’d be interested in providing stronger type hints in the new
> remote protocol in development under remote/, as I understand
> adding types retroactively to existing code can be challenging.

>
> > For the time being the perf tools team will just be checking the types
> > locally before committing. This will give us an idea of the benefits on
> > real in-tree code without any impact outside of the team.
>

> Has any progress been made since to include this in our lint checks?
>
> If not, what instructions do I need for running the manual checks?
>
>

[Michael Cooper (mythmon)]

>
> I know from the folks talking about types earlier, we're definitely
> interested in other teams adopting some TypeScript comments in their own
> areas of the codebase, so we can gather more feedback. If anyone is
> interested in experimenting, I'd be happy to help guide some initial setup.
>

I'd like to explore adding this to the Normandy code
(toolkit/components/normandy). We already often annotate types via JSDoc
comments, though nothing so strict as what Typescript would want. I expect
the code would be pretty amicable to being strongly typed as well.

>> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>

[Andreas Tolfsen]