Re: Experimenting with JavaScript type safety in mozilla-central

[Julian Descottes]

We are going to prototype a WebDriver Bidi (https://w3c.github.io/webdriver-bidi/) implementation in mozilla-central.

This will be implemented in JavaScript and will mostly be written from scratch (although inspired from DevTools and Remote Agent).

We are discussing about using TypeScript comments for this new code, but I can see that TS is still only used in DevTools' performance-new panel for now.

What is the status of TypeScript in mozilla-central? Is it fine if a new project starts using it?

Thanks!

On Wed, Nov 13, 2019 at 12:45 AM Michael Cooper (mythmon) <mco...@mozilla.com> wrote:

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.

On Tue, Nov 12, 2019 at 1:33 PM Greg Tatum <gta...@mozilla.com> wrote:

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?

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

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

[Nick Alexander]

Hi folks,

On Wed, May 26, 2021 at 7:35 AM Julian Descottes <jdesc...@mozilla.com> wrote:

We are going to prototype a WebDriver Bidi (https://w3c.github.io/webdriver-bidi/) implementation in mozilla-central.

Yay!  I want this for a personal project; it's neat technology.

This will be implemented in JavaScript and will mostly be written from scratch (although inspired from DevTools and Remote Agent).

We are discussing about using TypeScript comments for this new code, but I can see that TS is still only used in DevTools' performance-new panel for now.

What is the status of TypeScript in mozilla-central? Is it fine if a new project starts using it?

I can't speak to the policy pieces here, but I would like to see projects start using type annotations of some type so that we get some local benefits and figure out whether we can get some global benefits in the future.  I think you are not suggesting using TypeScript (`.ts`) files with the `tsc` compiler, but I can speak to the technical bits for that: we don't support it in the build system at this time.  We have some limited support for invoking Node.js scripts at build time, and since `tsc` is itself implemented in Node.js it's almost certainly possible to support `.ts` files in the build.  But there are larger questions around vendoring and platform support that we don't have great answers for at this time.  So: type annotations in comments, yes (at least from me!); `.ts` files, not without some discussion and build system work.

Best,

Nick

[Greg Tatum]

TypeScript via JSDoc is "just JavaScript", so it should run fine whether it is checked by the TypeScript compiler or not. There is not a staffed project to bring broader support of TypeScript into Gecko (as far as I know), but the risks are fairly low since even if all TypeScript integrations are pulled, then what's leftover is JavaScript that will run fine, and readable JSDoc.

The types in performance-new are still being checked with the devtools node test runner, so it shouldn't be much of a burden to add more checks for additional code projects. Feel free to reach out if you have any questions on it.

[Julian Descottes]

Thanks for the feedback! 

We only plan to use annotations in comments, not TypeScript as a language.

Glad to see it's still ok to do this for new areas of the codebase. We will most likely use it for our Webdriver BiDi implementation.