Skip to content
A Starting template for an OpenRPC Server
Shell TypeScript JavaScript
Branch: master
Clone or download
Pull request Compare This branch is 2 commits behind ethernodeio:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci
.ebextensions
.elasticbeanstalk
.github/ISSUE_TEMPLATE
.pristine
src
.editorconfig
.gitignore
.npmrc
.releaserc
BUILDING.md
CHANGELOG.md
CIRCLECI.md
CONTRIBUTING.md
CONVENTIONAL_COMMITS.md
LICENSE.md
README.md
RELEASING.md
VERSIONING.md
jest.config.js
openrpc.json
package-lock.json
package.json
publish.sh
tsconfig.json
tsfmt.json
tslint.json
verifyConditions.sh

README.md

Pristine Typescript OpenRPC Server

A typescript OpenRPC Server repository in its original condition.

Pristine Typescript OpenRPC Server a fork of Pristine.

There are a lack of repositories to start from to build community driven open source projects. Pristine Typescript is a complete starting point, it follows a Documentation Driven Development approach, and can be used as a resource to augment existing documentation.

Setup

  1. To set up this repository you can use the pristine-cli and choose this repo to start from
  2. OR use it as a github template and run .pristine/post-install.sh

Generated Clients

This pristine OpenRPC starting point auto generates clients to interact with this server when released via semantic-release. You can test out the generated ones from this repo:

Typescript/Javascript

npm install @etclabscore/pristine-typescript-openrpc-server-client

Rust

add this to your Cargo.toml

pristine-typescript-openrpc-server-client = "1.1.2"

How to use Pristine in your project

There are 2 options for using pristine with your project.

  1. Fork this repo as the start of your own, OR
  2. follow these instructions to use it on an existing repository.

Documentation Driven Development

There are many ways to drive open source development. Documenting the problem in the README gives a middle ground between technical and non-technical specifications. This allows organizing solutions to this challenge around community and documentation.

[...] a beautifully crafted library with no documentation is also damn near worthless. If your software solves the wrong problem or nobody can figure out how to use it, there’s something very bad going on.

Conventions and Specifications

This repository has some strong opinions built in like circleci, semantic-release, npm. So feel free to fork and change it at your own discretion. It is only meant to be a starting point. That being said:

Using conventions, documentation and specifications make it easier to:

  • communicate the problem you are solving
  • ease onboarding
  • build and use composable tools
  • promote open source contribution and engagement
  • promote issue and feature discussion on Github itself

Resources

Getting Started

To get started, fork or duplicate the repository. Then edit this file and delete everything above this line.

Contributing

How to contribute, build and release are outlined in CONTRIBUTING.md, BUILDING.md and RELEASING.md respectively. Commits in this repository follow the CONVENTIONAL_COMMITS.md specification.

You can’t perform that action at this time.