chore: setup tooling

.dprint.jsonc

@@ -0,0 +1,20 @@
+{
+  "exec": {
+    "commands": [
+      {
+        "command": "rustfmt",
+        "exts": ["rs"],
+      },
+    ],
+  },
+  "prettier": {
+    "singleQuote": true,
+  },
+  "plugins": [
+    "https://plugins.dprint.dev/exec-0.4.4.json@c207bf9b9a4ee1f0ecb75c594f774924baf62e8e53a2ce9d873816a408cecbf7",
+    "https://plugins.dprint.dev/json-0.19.3.wasm",
+    "https://plugins.dprint.dev/markdown-0.17.1.wasm",
+    "https://plugins.dprint.dev/toml-0.6.2.wasm",
+    "https://plugins.dprint.dev/prettier-0.40.0.json@68c668863ec834d4be0f6f5ccaab415df75336a992aceb7eeeb14fdf096a9e9c",
+  ],
+}

.github/ISSUE_TEMPLATE/---bug.md

@@ -26,9 +26,9 @@ If applicable, add screenshots to help explain your problem.
 
 **Technologies (please complete the following information):**
 
--   Node.js version
--   NPM version
--   Solidity version
+- Node.js version
+- NPM version
+- Solidity version
 
 **Additional context**
 Add any other context about the problem here.

.github/pull_request_template.md

@@ -29,10 +29,10 @@
 
 <!-- Please check if the PR fulfills these requirements. -->
 
--   [ ] My code follows the style guidelines of this project
--   [ ] I have performed a self-review of my code
--   [ ] I have commented my code, particularly in hard-to-understand areas
--   [ ] My changes generate no new warnings
--   [ ] I have run `yarn format` and `yarn compile` without getting any errors
--   [ ] I have added tests that prove my fix is effective or that my feature works
--   [ ] New and existing unit tests pass locally with my changes
+- [ ] My code follows the style guidelines of this project
+- [ ] I have performed a self-review of my code
+- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] My changes generate no new warnings
+- [ ] I have run `yarn format` and `yarn compile` without getting any errors
+- [ ] I have added tests that prove my fix is effective or that my feature works
+- [ ] New and existing unit tests pass locally with my changes

.github/workflows/docs.yml

@@ -0,0 +1,38 @@
+name: docs
+on:
+  push:
+    branches: [main]
+    paths: ['src/**/*.rs', 'Cargo.toml', '.github/workflows/docs.yml']
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+      - uses: Swatinem/rust-cache@v2.7.3
+      - uses: actions/configure-pages@v5
+      - name: Build docs
+        run: |
+          make build.docs
+          # we need an index.html page (cargo doc doesn't create it)
+          # this will just redirect to target/doc/example/index.html
+          echo '<meta http-equiv="refresh" content="0;url=example/index.html">' > target/doc/index.html
+      - uses: actions/upload-pages-artifact@v3
+        with:
+          path: target/doc
+  deploy:
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: github-pages
+      url: ${{ steps.deploy.outputs.page_url }}
+    steps:
+      - uses: actions/deploy-pages@v4
+        id: deploy

.github/workflows/main.yml

@@ -1,40 +1,48 @@
 name: main
-
 on:
-    push:
-        branches:
-            - main
-    pull_request:
+  pull_request:
+    types: [opened, reopened, synchronize]
+    branches: [main]
+  push:
+    branches: [main]
 
 concurrency:
-    group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
-    cancel-in-progress: true
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
 
 jobs:
-    build:
-        runs-on: ubuntu-latest
-
-        steps:
-            - name: Checkout
-              uses: actions/checkout@v4
-
-            - name: Install Rust
-              uses: dtolnay/rust-toolchain@stable
-              with:
-                  toolchain: stable
-                  components: rustfmt, clippy
-
-            - name: Cache
-              uses: Swatinem/rust-cache@v2
-
-            - name: Build
-              run: cargo build --workspace --all-targets
-
-            - name: Run tests
-              run: cargo test --workspace --all-targets
-
-            - name: Run clippy
-              run: cargo clippy --workspace --all-targets -- -D warnings
-
-            - name: Run fmt check
-              run: cargo fmt -- --check
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+      - uses: Swatinem/rust-cache@v2.7.3
+      - run: make build
+
+  format:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: taiki-e/cache-cargo-install-action@v2.0.1
+        with:
+          tool: dprint
+      - run: make check
+
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+        with:
+          components: clippy
+      - uses: Swatinem/rust-cache@v2.7.3
+      - run: make lint
+
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: taiki-e/cache-cargo-install-action@v2.0.1
+        with:
+          tool: cargo-nextest
+      - run: cargo nextest run

.gitignore

@@ -1 +1,7 @@
-/target
+.cargo/*
+!.cargo/config.toml
+Cargo.lock
+target
+
+.envrc
+.tool-versions

.setup.sh

@@ -0,0 +1,99 @@
+#!/bin/sh
+set -eou pipefail
+
+ORANGE="\033[33m"
+RESET="\033[0m"
+
+log() {
+  printf "%b\n" "$1"
+}
+
+is_bin_locally_available() {
+  crate="$1"
+  [ -x ".cargo/bin/$crate" ]
+}
+
+install_local() {
+  crate="$1"
+  log "Installing $ORANGE$crate$RESET locally..."
+  cargo install --root .cargo "$crate"
+}
+
+maybe_install_local() {
+  crate="$1"
+  if ! is_bin_locally_available "$crate"; then
+    install_local "$crate"
+  else
+    log "  $ORANGE$crate$RESET already installed locally. Skipping."
+  fi
+}
+
+install_dev_deps() {
+  log "Installing development dependencies..."
+  crates="convco dprint cargo-nextest"
+
+  for crate in $crates; do
+    maybe_install_local "$crate"
+  done
+}
+
+write_pre_push_hook() {
+  cat >.git/hooks/pre-push <<'EOF'
+#!/bin/sh
+alias convco=.cargo/bin/convco
+
+# https://convco.github.io/check/
+z40=0000000000000000000000000000000000000000
+
+while read -r _ local_sha _ remote_sha; do
+  if [ "$local_sha" != $z40 ]; then
+    if [ "$remote_sha" = $z40 ]; then
+      # New branch, examine all commits
+      range="$local_sha"
+    else
+      # Update to existing branch, examine new commits
+      range="$remote_sha..$local_sha"
+    fi
+
+    # Check only the commits that are not in main
+    merge_base=$(git merge-base "$local_sha" main)
+    if [ -n $merge_base ];then
+      range="$merge_base..$local_sha"
+    fi
+
+    # Check for WIP commit
+    if ! convco check "$range"; then
+      exit 1
+    fi
+  fi
+done
+EOF
+
+  chmod +x .git/hooks/pre-push
+  log "  .git/hooks/pre-push (conventional commits linting)"
+}
+
+write_pre_commit_hook() {
+  echo "make fmt" >.git/hooks/pre-commit
+  chmod +x .git/hooks/pre-commit
+  log "  .git/hooks/pre-commit (formatting)"
+}
+
+write_hooks() {
+  log "Writing hooks..."
+  write_pre_commit_hook
+  write_pre_push_hook
+}
+
+end_log() {
+  log "===================\nTo get started, you can run the make tasks defined in the Makefile.\n"
+  make help
+}
+
+main() {
+  install_dev_deps
+  write_hooks
+  end_log
+}
+
+main

CODE_OF_CONDUCT.md

@@ -17,24 +17,24 @@ diverse, inclusive, and healthy community.
 Examples of behavior that contributes to a positive environment for our
 community include:
 
--   Demonstrating empathy and kindness toward other people
--   Being respectful of differing opinions, viewpoints, and experiences
--   Giving and gracefully accepting constructive feedback
--   Accepting responsibility and apologizing to those affected by our mistakes,
-    and learning from the experience
--   Focusing on what is best not just for us as individuals, but for the
-    overall community
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the
+  overall community
 
 Examples of unacceptable behavior include:
 
--   The use of sexualized language or imagery, and sexual attention or
-    advances of any kind
--   Trolling, insulting or derogatory comments, and personal or political attacks
--   Public or private harassment
--   Publishing others' private information, such as a physical or email
-    address, without their explicit permission
--   Other conduct which could reasonably be considered inappropriate in a
-    professional setting
+- The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
 
 ## Enforcement Responsibilities
 

CONTRIBUTING.md

@@ -30,7 +30,7 @@ Pull requests are great if you want to add a feature or fix a bug. Here's a quic
 
 7. Push to your fork and submit a pull request on our `main` branch. Please provide us with some explanation of why you made the changes you made. For new features make sure to explain a standard use case to us.
 
-> [!NOTE]  
+> [!NOTE]\
 > When a new package is created or a new feature is added to the repository, the contributor will be added to the `.github/CODEOWNERS` file to review and approve any future changes to their code.
 
 ## CI (Github Actions) Tests
@@ -63,17 +63,17 @@ The **header** is mandatory and the **scope** of the header is optional.
 
 The type must be one of the following:
 
--   feat: A new feature
--   fix: A bug fix
--   docs: Documentation only changes
--   style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
--   refactor: A code change that neither fixes a bug nor adds a feature (improvements of the code structure)
--   perf: A code change that improves the performance
--   test: Adding missing or correcting existing tests
--   build: Changes that affect the build system or external dependencies (example scopes: gulp, npm)
--   ci: Changes to CI configuration files and scripts (example scopes: travis, circle)
--   chore: Other changes that don't modify src or test files
--   revert: Reverts a previous commit
+- feat: A new feature
+- fix: A bug fix
+- docs: Documentation only changes
+- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- refactor: A code change that neither fixes a bug nor adds a feature (improvements of the code structure)
+- perf: A code change that improves the performance
+- test: Adding missing or correcting existing tests
+- build: Changes that affect the build system or external dependencies (example scopes: gulp, npm)
+- ci: Changes to CI configuration files and scripts (example scopes: travis, circle)
+- chore: Other changes that don't modify src or test files
+- revert: Reverts a previous commit
 
 #### Scope
 
@@ -83,23 +83,23 @@ The scope should be the name of the npm package affected (as perceived by the pe
 
 The subject contains a succinct description of the change:
 
--   Use the imperative, present tense: "change" not "changed" nor "changes"
--   Don't capitalize the first letter
--   No dot (.) at the end
+- Use the imperative, present tense: "change" not "changed" nor "changes"
+- Don't capitalize the first letter
+- No dot (.) at the end
 
 #### Body
 
 Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
 
 ### Branch rules
 
--   There must be a `main` branch, used only for the releases.
--   Avoid long descriptive names for long-lived branches.
--   Use kebab-case (no CamelCase).
--   Use grouping tokens (words) at the beginning of your branch names (in a similar way to the `type` of commit).
--   Define and use short lead tokens to differentiate branches in a way that is meaningful to your workflow.
--   Use slashes to separate parts of your branch names.
--   Remove branch after merge if it is not important.
+- There must be a `main` branch, used only for the releases.
+- Avoid long descriptive names for long-lived branches.
+- Use kebab-case (no CamelCase).
+- Use grouping tokens (words) at the beginning of your branch names (in a similar way to the `type` of commit).
+- Define and use short lead tokens to differentiate branches in a way that is meaningful to your workflow.
+- Use slashes to separate parts of your branch names.
+- Remove branch after merge if it is not important.
 
 Examples: