Skip to content

Dart GSoC 2021 Project Ideas

Jonas Finnemann Jensen edited this page Feb 18, 2021 · 11 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 gist, or simply github repository. Suggested ideas for code samples include:

⚠️ TODO: Clear directions for sample code.

Do not spend too much energy on this piece of sample code, we just want to see that you can code something relevant. 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. Students are encouraged to submit draft proposals, ideally linking to a Google Docs with permission for mentors to comment. See also the student guide on writing a proposal.

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


⚠️ TODO: Insert additional good ideas from our draft document.


Idea: Standalone pub-server

Description: Write a standalone pub server following the hosted pub repository specification. Goal could be to allow vendors to host private pub repositories for commercial packages, and/or facilitate internally mirroring of pub.dev for organizations with outgoing network restrictions. In addition to implementing a server, certain tweaks to the pub tool might be required for authentication with 3rd party servers.

Getting Started Figure out how to make a webserver in Dart using shelf, workout how to render HTML templates, convert Dart to JS for use clientside, handle REST requests and generally familarize yourself with the Dart server stack.


Idea: Extends git source in pubspec.yaml to understand tags

Description: Currently, pubspec.yaml can contain git dependencies. However, pub does not support walking through the list of tags in a git repository and finding all versions of the pubspec.yaml in the repository. Hence, a git dependency always has exactly one version. What if pub could find all versions of a package from a git repository, and use those versions in the solver.

Getting Started Explore existing support for git dependencies in Dart, figure out how to work with --references in git repositories, as well as commands for listing a specific file pubspec.yaml from various tags in a repository. Explore to what extend tags and files can be listed remotely without downloading the entire repository.


Idea: SPDX license detection package

  • Possible Mentor(s): [email protected]
  • Difficulty: easy
  • Skills: Dart programming skills; text parsing.

Description: Write a Dart package for detecting SPDX license from a LICENSE file following the SPDX License List Matching Guidelines or text similarity like licensee does. A goal would be properly represent the license of a package on pub.dev with an SPDX identifier. Stretch goal might be to handle LICENSE files with multiple licenses and display an SPDX license expression on pub.dev.

Getting Started Try writing a small sample program that can fetch one of the SPDX master files and print it to terminal as markdown. Don't make it too perfect, just figure out how to parse the XML. For the proposal, it would be valuable to include:

  • Comparison of text similarity approach to SPDX matching guidelines,
  • References to relevant documentation.
  • A discussion of strategies for handling complicated cases with multiple licenses in the same file.
  • An API outline for the package, what does the function signatures look like?
  • List of features you would consider adding? what are the stretch goals? What should be omitted to keep it simple/robust?
  • How do we plan to test this? What test cases can we find? How can we become reasonably confident the implementation handles all corner cases?

Template for additional ideas

## **Idea:** {{title}}

 - **Possible Mentor(s)**: `{{email}}`
 - **Difficulty**: {{easy | medium | advanced}}
 - **Skills**: {{keyword}}; ...

**Description**:
{{description}}

**Getting Started**
{{how to get started; good first bugs; ideas for code samples; warm-up exercises}}

----
Clone this wiki locally