Skip to content

Dart GSoC 2024 Project Ideas

Jump to bottom
Jonas Finnemann Jensen edited this page Mar 5, 2024 · 20 revisions

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

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

Potential mentors

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 2nd deadline.

Idea: FFIgenpad

  • Possible Mentor(s): @dcharkes @mannprerak2 @eyebrowsoffire
  • Difficulty: Hard
  • Project size: Large (350 hours)
  • Skills: C, WASM, Web development, Dart

Description:

Original idea: A web interface in which you paste a C header in a textbox on the left, and it outputs dart:ffi bindings generated by package:ffigen in a textbox on the right. (Inspiration is https://godbolt.org/ which does this for a C file on the left and assembly on the right.)

In order to avoid needing a server to do the backend, we'd like to compile the Dart code in package:ffigen and libclang to WASM. That way everything can run in the browser.

Good Sample Project:

  • Compile some C code to WASM and call it from a web app.
  • Compile some Dart code to WasmGC and call it from a web app.
  • Explore compiling libclang from the llvm repository to WASM.

Expected outcome: A web app (possibly hosted on github.io).

Idea: Swift/ObjC compatibility tool

  • Possible Mentor(s): @liamappelbe
  • Difficulty: Hard
  • Project size: Large (350 hours)
  • Skills: Swift

Description:

package:ffigen allows Dart to interact with ObjC. Swift modules can be invoked from ObjC (and Dart through ffi), but only if the classes and methods have been annotated with @objc. So if a user wants to interact with a Swift module they don't own from Dart, they need to write a wrapper module that mirrors the API, but has @objc annotations.

It should be possible to write a tool that can automatically generate this ObjC compatibility wrapper. The official Swift parsing library is written in Swift, so the tool should probably also be written in Swift. In fact, the candidate doesn't even really need any Dart experience, just Swift and ObjC.

Good Sample Project: Use the Swift parsing library to load a module and print some of its metadata (e.g. print a list of the classes in the module).

A great project proposal will also talk about which Swift language features can be feasibly supported by this tool. For example, is it possible to write an @objc wrapper method for an async Swift method? What would that look like? Swift is a modern language, and ObjC is not, so there are probably a lot of features that will be problematic to wrap in a compatibility class.

Expected outcome: A dart package available on pub.dev.

Idea: JNIgen transformations

  • Possible Mentor(s): @HosseinYousefi
  • Difficulty: Hard
  • Project size: Large (350 hours)
  • Skills: Dart, Java

Description: Add the ability to rename, exclude, convert to operators, add members, and generally transform the classes and methods using visitor pattern. Something like this:

Config(
  visitors: [Foo2BarRenamer()], // User passes the visitor to config
);

class Foo2BarRenamer extends JnigenVisitor {
  void visitClass(Class c) {
    if (c.name == 'foo') c.name = 'bar';
    c.visitMethods(this);
    // ...
  }
  // ...
}

Good Sample Project: Create a simple renamer/excluder visitor, so JNIgen users can pass that in, and rename/exclude classes, methods, and fields. You will have to create a user-facing AST that wraps the original AST. For the sample project, the wrapper AST could only expose name or included properties.

Expected outcome: A new set of features for package:jnigen.

Idea: Integrate OkHttp with Dart

Description: Write a flutter plugin that wraps the OkHttp package using package:jnigen and implements the package:http Client interface. Time permitting, the plugin will also implement the package:web_socket_channel WebSocketChannel interface. This will allow us to provide several features requested by our users such as:

  • Support for KeyStore PrivateKeys (#50669)
  • Support for the system proxy (#50434)
  • Support for user-installed certificates (#50435)

Successfully completely this project will likely involve:

  • Determining exactly what APIs should be make available in Dart.
  • Creating a JNI bindings for those APIs using package:jnigen.
  • Creating a package:http Client implementation using those bindings.
  • Verifying that the Client implementation passes the conformance tests.

You'll like working on this project because:

  • It will be easy to implement incrementally. After the basic functionality is present, more advanced APIs can be added as time permits.
  • There are existing conformance tests to validate the correctness of the work.
  • Dart users want it!

A good project proposal will describe what Java APIs are necessary to implement the package:http Client interface e.g. OkHttpClient.newCall(). An excellent proposal will use asynchronous APIs.

Good Sample Project: Try writing a small Flutter application that makes HTTP requests using OkHttp bindings created with package:jnigen. You can use package:cronet_http and package:java_http as starting points.

Tip

Look at the package:cronet_http jnigen.yaml and build.gradle files.

Expected outcome: A dart package available on pub.dev.

Idea: Exception testing for package:webcrypto

Description: package:webcrypto (github.com/google/webcrypto.dart) is a cross-platform implementation of the Web Cryptography API. It is important that it behaves the same way whether it's running on Windows, Linux, Mac, Android, iOS, Chrome, Firefox, or Safari. Towards that end, it has a lot of test cases. We could and should probably make more test cases. But we should also test that it throws the types of exceptions when given incorrect parameters. This probably needs a small test framework to ensure good test coverage.

We expect a proposal for this project to include:

  • A sample showing how to test exceptions for RsaPssPrivateKey.generateKey. Ideally, the sample project includes parts of a generalized framework for testing exceptions.
  • An outline of what kind of exceptions should be tested?
  • A design for extending TestRunner, or creating a new framework, to test exceptions thrown by all methods.
    • Illustrative code for how test cases would be configured
    • Pros and cons of the design (especially when multiple choices are available)
  • Timeline for the project

Good Sample Project: Write a test cases that tests the different kinds of errors and exceptions that can be thrown by RsaPssPrivateKey.generateKey, run the tests across desktop, Chrome and Firefox. Consider extending the tests to cover all members of RsaPssPrivateKey. Try to generalize these test cases to avoid repetitive code, see the existing TestRunner for inspiration.

Expected outcome: PRs that land in package:webcrypto and increases our confidence in correctness cross-platforms.

Idea: Testing documentation comments

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: Create a function that given some Dart code will use package:analyzer to do static analysis of the code and count static errors. Additional step would be to try and use package:analyzer to extract documentation comments from source code and use package:markdown to extract code-snippets from source code comments, and then run analysis on the extracted source code snippets. Ideally, all of this could be done, in-memory without writing files to disk.

Useful hints: analyzer tutorial | analyzer API docs | analyzer file_system abstraction.

Template:

Copy this template.

Idea: ...

  • Possible Mentor(s):
  • Difficulty: Easy / Hard
  • Project size: Small (90) / Medium (175 hours) / Large (350 hours)
  • Skills: ...

Description: ...

Good Sample Project: ...

Expected outcome: ...

Important

The wiki has moved to https://github.com/dart-lang/sdk/tree/main/docs; please don't edit the pages here.

Clone this wiki locally