Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/rryter/solidity-playground
Playground for experimentation with Solidity and co.
https://github.com/rryter/solidity-playground
solidity typescript
Last synced: 20 days ago
JSON representation
Playground for experimentation with Solidity and co.
- Host: GitHub
- URL: https://github.com/rryter/solidity-playground
- Owner: rryter
- Created: 2020-10-22T12:33:47.000Z (about 4 years ago)
- Default Branch: main
- Last Pushed: 2023-01-24T04:26:50.000Z (almost 2 years ago)
- Last Synced: 2024-12-17T10:46:00.845Z (24 days ago)
- Topics: solidity, typescript
- Language: Solidity
- Homepage:
- Size: 4.2 MB
- Stars: 9
- Watchers: 2
- Forks: 4
- Open Issues: 13
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
Awesome Lists containing this project
README
# ERC-725 Playground
[](https://www.npmjs.org/package/@twy-gmbh/erc725-playground)
[](https://travis-ci.com/rryter/solidity-playground)
[](https://conventionalcommits.org)
## Do not use this yet.
Most of the sourcecode of the contracts comes from https://github.com/ERC725Alliance/ERC725/tree/master/implementations.
This is just an experimentation / learning space for Solidity, Typechain and Hardhat.
## Compile
```
npm run build
```
## Publish a new version
```
npm run release
```
## Tests
How to run all the tests
```
jest
```
### Watch mode:
```
jest --watch
```
## Conventional commits
The Conventional Commits specification is a lightweight convention on top of commit messages.
It provides an easy set of rules for creating an explicit commit history;
which makes it easier to write automated tools on top of.
This convention dovetails with [SemVer](http://semver.org),
by describing the features, fixes, and breaking changes made in commit messages.
The commit message should be structured as follows:
---
```
[optional scope]:
[optional body]
[optional footer(s)]
```
---
The commit contains the following structural elements, to communicate intent to the
consumers of your library:
1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in semantic versioning).
1. **BREAKING CHANGE:** a commit that has a footer `BREAKING CHANGE:`, or appends a `!` after the type/scope, introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning).
A BREAKING CHANGE can be part of commits of any _type_.
1. _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `build:`, `chore:`,
`ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
1. _footers_ other than `BREAKING CHANGE: ` may be provided and follow a convention similar to
[git trailer format](https://git-scm.com/docs/git-interpret-trailers).
Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE).
A scope may be provided to a commit's type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`.