Initial commit

Signed-off-by: Sri Krishna <[email protected]>

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,3 @@
+## Community Code of Conduct
+
+Connect follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

.github/CONTRIBUTING.md

@@ -0,0 +1,74 @@
+Contributing
+============
+
+We'd love your help making `connect-dart` better!
+
+If you'd like to add new exported APIs, please [open an issue][open-issue]
+describing your proposal — discussing API changes ahead of time makes
+pull request review much smoother. In your issue, pull request, and any other
+communications, please remember to treat your fellow contributors with
+respect!
+
+Note that for a contribution to be accepted, you must sign off on all commits
+in order to affirm that they comply with the [Developer Certificate of Origin][dco].
+
+## Setup
+
+[Fork][fork], then clone the repository:
+
+```
+git clone [email protected]:your_github_username/connect-dart.git
+cd connect-dart
+git remote add upstream https://github.com/connectrpc/connect-dart.git
+git fetch upstream
+```
+
+Make sure that the tests and the linters pass (you'll need `bash` and the
+latest stable dart release installed):
+
+```
+dart pub get # download deps
+dart pub global activate melos # one time action to setup melos cli
+melos run all
+```
+
+## Making Changes
+
+Start by creating a new branch for your changes:
+
+```
+git checkout main
+git fetch upstream
+git rebase upstream/main
+git checkout -b cool_new_feature
+```
+
+Make your changes, then ensure that `melos run all` still passes. When you're satisfied with your changes,
+push them to your fork.
+
+Ensure to update [CHANGELOG.md](/packages/connect/CHANGELOG.md). Only changes that impact users should be listed. 
+No need to list things like doc changes (unless it’s something major), dependency version bumps, or similar. 
+Remove them from the generated release notes.
+
+```
+git commit -a
+git push origin cool_new_feature
+```
+
+Then use the GitHub UI to open a pull request.
+
+At this point, you're waiting on us to review your changes. We *try* to respond
+to issues and pull requests within a few business days, and we may suggest some
+improvements or alternatives. Once your changes are approved, one of the
+project maintainers will merge them.
+
+We're much more likely to approve your changes if you:
+
+* Add tests for new functionality.
+* Write a [good commit message][commit-message].
+* Maintain backward compatibility.
+
+[fork]: https://github.com/connectrpc/connect-dart/fork
+[open-issue]: https://github.com/connectrpc/connect-dart/issues/new
+[dco]: https://developercertificate.org
+[commit-message]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,31 @@
+---
+name: Bug report
+about: Let us know about a bug
+title: ""
+labels: bug
+assignees: ""
+---
+
+**Describe the bug**
+
+As clearly as you can, please tell us what the bug is.
+
+**To Reproduce**
+
+If you encountered an error message, please copy and paste it verbatim.
+If the bug is specific to an RPC or payload, please provide a reduced
+example.
+
+**Environment (please complete the following information):**
+
+- connectrpc version: (for example, `0.1.0`)
+- Dart SDK version: (for example, `>=3.3.0 <4.0.0`)
+- Flutter SDK version: (for example `>=3.21.0`)
+- Platform/Device and version: (for example, `iOS 18/iPhone 16`)
+
+```dart
+
+```
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest a new feature or improvement
+title: ""
+labels: enhancement
+assignees: ""
+---
+
+**Is your feature request related to a problem? Please describe.**
+What's the problem? For example, "I'm always frustrated when..."
+
+**Describe the solution you'd like**
+What would you like to have `connect-dart` do? How should we solve the problem?
+
+**Describe alternatives you've considered**
+If you've proposed a solution, are there any alternatives? Why are they worse
+than your preferred approach?
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/RELEASING.md

@@ -0,0 +1,38 @@
+# Releasing
+
+## Prerequisites
+
+- See the setup and tools required in CONTRIBUTING.md
+- Login using `dart pub login` with an account that has publish access to `connectrpc` package.
+- Make sure that the repository is in a good state, without PRs close to merge
+  that would ideally be part of the release.
+
+## Steps
+
+1. Choose a new version (e.g. 1.2.3), making sure to follow semver. Note that all
+   packages in this repository use the same version number.
+2. Make sure you are on the latest main, and create a new git branch.
+3. Set the new version in [pubspec.yaml](/packages/connect/pubspec.yaml)
+4. Commit, push, and open a pull request with the title "Release 1.2.3".
+5. Edit the PR description with release notes. See the section below for details.
+6. Make sure CI passed on your PR and ask a maintainer for review.
+7. After approval, run the following command to publish to pub.dev: `dart pub publish`.
+8. Merge your PR.
+9. Create a new release in the GitHub UI
+   - Choose "v1.2.3" as a tag and as the release title.
+   - Copy and paste the release notes from the PR description.
+   - Check the checkbox “Create a discussion for this release”.
+
+## Release notes
+
+- We generate release notes with the GitHub feature, see
+  https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes
+- Only changes that impact users should be listed. No need to list things like
+  doc changes (unless it’s something major), dependency version bumps, or similar.
+  Remove them from the generated release notes.
+- If the release introduces a major new feature or change, add a section at the
+  top that explains it for users.
+- If the release includes a very long list of changes, consider breaking the
+  changelist up with the sections "Enhancements", "Bugfixes", "Breaking changes".  
+- If the release includes changes specific to a npm package, group and explain
+  the changelist in according separate sections.

.github/workflows/add-to-project.yaml

@@ -0,0 +1,21 @@
+name: Add issues and PRs to project
+
+on:
+  issues:
+    types:
+      - opened
+      - reopened
+      - transferred
+  pull_request_target:
+    types:
+      - opened
+      - reopened
+  issue_comment:
+    types:
+      - created
+
+jobs:
+  call-workflow-add-to-project:
+    name: Call workflow to add issue to project
+    uses: connectrpc/base-workflows/.github/workflows/add-to-project.yaml@main
+    secrets: inherit

.github/workflows/ci.yaml

@@ -0,0 +1,32 @@
+name: ci
+on:
+  push:
+    branches: [main]
+    tags: ["v*"]
+  pull_request:
+    branches: [main]
+  workflow_dispatch: {} # support manual runs
+permissions:
+  contents: read
+jobs:
+  ci:
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        os: [ubuntu-latest, windows-latest]
+    steps:
+      - run: git config --global core.autocrlf false # For windows
+      - uses: actions/checkout@v4
+      - uses: dart-lang/setup-dart@v1
+        with:
+          sdk: stable # TODO: Use a matrix instead to test multiple versions if needed.
+      - uses: bufbuild/[email protected]
+      - name: pub get
+        run: dart pub get
+      - name: activate melos
+        run: dart pub global activate melos
+      - name: all
+        run: melos run all
+      - name: Check Diff 
+        # Windows runs powershell, we have to use different commands for that.
+        run: ${{ startsWith(matrix.os, 'windows') && 'if (-not ([string]::IsNullOrEmpty((git status --porcelain)))) { git diff; exit 1 }' || '[[ -z $(git status --porcelain | tee /dev/stderr) ]] || exit 1' }}

.github/workflows/pr-title.yaml

@@ -0,0 +1,18 @@
+name: Lint PR Title
+# Prevent writing to the repository using the CI token.
+# Ref: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#permissions
+permissions:
+  pull-requests: read
+on:
+  pull_request:
+    # By default, a workflow only runs when a pull_request's activity type is opened,
+    # synchronize, or reopened. We explicity override here so that PR titles are
+    # re-linted when the PR text content is edited.
+    types:
+      - opened
+      - edited
+      - reopened
+      - synchronize
+jobs:
+  lint:
+    uses: bufbuild/base-workflows/.github/workflows/pr-title.yaml@main

.gitignore

@@ -0,0 +1,34 @@
+
+*.swp
+*.exe
+
+# Files and directories created by pub
+.dart_tool/
+.packages
+build/
+# If you're building an application, you may want to check-in your pubspec.lock
+pubspec.lock
+
+# Directory created by dartdoc
+# If you don't generate documentation locally you can remove this line.
+doc/api/
+
+# dotenv environment variables file
+.env*
+
+# Avoid committing generated Javascript files:
+*.dart.js
+*.info.json      # Produced by the --dump-info flag.
+*.js             # When generated by dart2js. Don't specify *.js if your
+                 # project includes source files written in JavaScript.
+*.js_
+*.js.deps
+*.js.map
+
+.flutter-plugins
+.flutter-plugins-dependencies
+
+.tmp
+
+# Generated by melos
+pubspec_overrides.yaml