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? > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
