Dart GSoC 2023 Project Ideas

A list of Google Summer of Code project ideas for Dart.

For GSoC related discussions please use the dart-gsoc group.

Potential mentors

• Jonas Jensen (jonasfj) jonasfj@google.com
• Daco Harkes (dcharkes) dacoharkes@google.com
• Sigurd Meldgaard (sigurdm)‎ sigurdm@google.com
• Liam Appelbe‎ (liamappelbe) liama@google.com

Project Application Process

All projects assume familiarity with Dart (and sometimes Flutter). Aspiring applicants are encouraged to learn Dart and try to write some code.

Applicants are welcome to find and fix bugs in Dart or some of the packages written by the Dart team. However, getting reviews can take a long time as code owners may be busy working on new features. So instead of requiring applicants to fix a good first bug, we suggest that applicants write a working code sample relevant for the proposed project.

The code sample can be attached to the application as a secret gist (please use secret gists, and do not share these with other applicants). Suggested ideas below includes proposed "Good Sample Projects".

Do not spend too much energy on this piece of sample code, we just want to see that you can code something relevant -- and that this sample code can run and do something non-trivial. Be aware that we have a limited number of mentors available, and will only be able to accept a few applicants.

Applications can be submitted through the summerofcode.withgoogle.com website. Applicants are encouraged to submit draft proposals, linking to Google Docs with permission for mentors to comment. See also the contributor guide on writing a proposal.

IMPORTANT: Remember to submit final proposals before the April 4th deadline.

Idea: GOgen

• Possible Mentor(s): dacoharkes@google.com
• Difficulty: Hard
• Project size: / Large (350 hours)
• Skills: Dart, Go

Description: Package FFIgen makes interop with C and Objective-C seamless, and the (experimental) package JNIgen does the same for Java and Kotlin. However, what about Go?

In this project we would parse Go files and generate C wrappers and Dart bindings to those C wrappers so that developers can easily interop with Go from Dart.

1. Design a way to interop with Go. We can explore cgo, is this at the right abstraction level for interop? Or would we want a more high level interaction? For example, since Go is garbage collected, can we have handles to Go data structures from Dart that prevent them from being Garbage collected?
2. Design an approach to get the right information from a Go API. This will likely involve a Go parser and static analysis tool. That data structure then needs to be made accessible in Dart (either serialization such as in JNIgen or with direct FFI as in FFIgen).
3. Generate the code that does 1 and 2.
4. Profit!

(Alternatively, we could also do this project for another language. IDL, C++, Rust, …)

Good Sample Project: (1) Build a small sample project where you interop with a Go library. (2) Build a prototype for generating the bindings for that library, and (3) use a Go parser to generate those bindings.

---

Idea: Testing documentation comments

• Possible Mentor(s): jonasfj@google.com, sigurdm@google.com
• Difficulty: Hard
• Project size: Large (350 hours)
• Skills: Dart, static analysis

Description: When writing Dart code it is useful to write documentation comments, such comments will be included in automatically generated documentation created by dartdoc. Documentation comments for dartdoc are written in markdown, which allows authors to embed code samples. This project aims to create tools for testing code samples embedded in documentation comments.

This will likely involve:

• Using package:analyzer to extract documentation comments.
• Using package:markdown to extract code samples.
• Testing these code samples by:
  • Running dart analyze on the code sample,
  • Passing the code sample through dart format, and/or,
  • Running the code sample in an isolate and compare stdout to comments from the sample.

For this project, we'll finish the dartdoc_test package, such that it can be used by package authors who wish to test code samples in their documentation comments.

As part of this project, we'll likely have to define conventions for what is expected of a code sample in documentation comments:

• What libraries (if any) are implicitly imported?
• Can you make code samples that are excluded from testing?
• Can comments inside the code sample be used to indicate expected output in stdout?
• How should code be written?
  • Do all code samples need a main function?
  • Do we wrap top-level code in an implicit main to keep it simple?
  • Do we run the top-level function if it has a name other than main?
• Do we allow dead-code in samples (without an // ignore: unreachable comment)?
• What lints do we apply to sample code (same as the top-level project).

Some of these questions might be debated in the project proposal. A project proposal should also discuss how package authors would run the code sample tests. Finally, a project proposal is encouraged to outline implementation stages, including strech goals.

Good Sample Project: Build a function that given some Dart code as a string will run analysis on the Dart code and count static errors (feel free to extend with lints, etc).

---

Idea: TODO

• Possible Mentor(s): TODO
• Difficulty: Hard / Easy
• Project size: Medium (175 hours) / Large (350 hours)
• Skills: Dart, TODO

Description: TODO

Good Sample Project: TODO