This project focuses on migrating JavaScript codebase to Typescript. Zulip is in the process of porting the main web app JavaScript codebase to TypeScript. The challenges for migrating JS to TS include circular imports, a large number of interdependent modules, tracking down complex cycles, multiple cycles in one module, order of conversion, and understanding types and their relationships. The proposed solutions include classifying circular imports, passing callback workaround, extracting common functionality into a third module, and writing unit and integration tests to ensure the migrated codebase functions properly.
I created a checklist issue #25842 tracking the typescript migration progress as of the entire TypeScript migration project.
Various .js modules are migrated to .ts. Each is marked by type annotations, assertions for type safety, and custom type definitions to facilitate clean and understandable code. While the test code remains in JavaScript, some segments necessitate rewriting to align with the type definitions brought about by the migration. This is particularly important in scenarios where previously loosely defined data structures within test code need to be more precisely defined due to TypeScript's rigorous type system.
A complete list of migrations done by me is given in the Merged PRs and Open PRs under review sections.
Additionally, I contribute to improving the accuracy of type definitions for third-party JavaScript packages that I integrate through the DefinitelyTyped repository. For instance, in the case of @types/plotly.js-basic-dist, I identified and corrected missing type information by submitting a pull request to the package's type codebase. Specifically, I added the missing data property to the PlotlyHTMLElement type, aligning it with the official plotly.js specifications, referenced examples, and documentation. This collaborative effort ensures that TypeScript can effectively understand and interact with these packages, enhancing overall code reliability and developer experience.
Zod is a TypeScript schema validation library that enables developers to define and enforce data structures and formats in their codebase. In the context of the Zulip codebase, Zod is used to enhance data validation and maintain data integrity, especially enforcing the data structures received from the backend.
Here is a list of PRs/commits that implement zod data validation in our codebase.
This summer in total I contributed 4000+ lines of code, where 2200+ lines of code for migration, and 1800+ for the miscellaneous changes. According to the project checklist #25842, Zulip's TypeScript migration project has gone through 34%, still leaving 66% of work undone.
According to checklist #25842, there are 66% of files awaiting migration. Some of the migrations are crucial as they are the dependencies of some other migration branches. Many of them involve cyclic imports, which might need great effort to do refactorings or break cycles before migration.
#26544 bot_data: Fix owner_id field to allow null value.
#26502 bot_data: Eliminate owner field.
#26418 ts: Migrate settings_ui.js to TypeScript.
#26417 ts: Migrate stream_create_subscribers_data.js and user_group_create_members_data.js to TypeScript.
#26344 ts: Migrate huddle_data.js to TypeScript.
#26335 ts: Migrate alert_words.js to TypeScript.
#26315 ts: Migrate bot_data.js to TypeScript
#26272 ts: Migrate vdom.js to TypeScript
#26140 ts: Migrate stats.js to TypeScript
#25999 ts: Convert signup.js to TypeScript
#25948 ts: Convert stream_settings_containers.js to TypeScript.
#26585 ts: Migrate poll_widget.js to TypeScript
#26505 ts: Migrate compose_fade_helper.js , compose_fade_users.js, and recent_topics_util.js to TypeScript.
#26333 ts: Migrate message_store.js to TypeScript.
#25864 ts: Convert part of web/src/portico module to TypeScript.
#25141 realm: Replace occurences of uri with url.
#25874 ts: Migrates web/shared/poll_data to typescript.
#26507 ts: Migrate channel.js module to TypeScript.
Learning Git and GitHub involves an evolution of thought processes. At first (before GSoC), there was the challenge of grasping fundamental concepts like commits and branches, often leading to caution due to fear of irreversible mistakes. As familiarity grows, experimenting with branches and merges becomes more confident, accompanied by a realization that mistakes are fixable. The mindmap of getting git to work became clearer. The lightbulb moment arrives when pull requests and code reviews showcase the collaborative power of Git and GitHub. Every time I traced back the older commits by previous contributors, PRs, and their conversations, I greatly appreciated the power of the version control system in team collaboration. The shift from isolated coding to contributing within a team environment emerges as a significant mindset change. The journey also includes learning error-handling strategies, optimizing commits for clarity, and understanding the flow of code changes from "diff" perspectives. Overall, it's a transformation from apprehension to a mindset of adaptable collaboration and streamlined version control.
Looking at the compiler detect and highlight potential issues during the migration process reinforces the understanding that these errors would have remained hidden in a purely JavaScript codebase, only to surface later as runtime bugs. This realization gives me a sense of accomplishment as each migrated module strengthens the overall robustness of the application.
I greatly appreciate my mentors @Priyank Patel, @Tim Abbot, @Zixuan James Li, and buddy @Lalit Kumar, who guided a lot of valuable conversations. It's their support that allowed me to make important implementation decisions and learn a developer's mindset.
I would like to work on this project. Is there any documentation to get started for this project?