const Api = require('@polkadot/api').default
+const WsProvider = require('@polkadot/api-provider/ws').default
+const provider = new WsProvider('ws://127.0.0.1:9944')
+const api = new Api(provider)
+
+async function getChain () {
+ return api.system.chain()
+}
+
+async function main () {
+ const chain = await getChain()
+ console.log('You are connected to chain:', chain)
+}
+
+main().finally(_ => process.exit())
+
+
+
+
+
+
+
+
+
+
+
+
+ Contributing
+
+
+What?
+
+
+
+
+Individuals making significant and valuable contributions are given commit-access to a project to contribute as they see fit. +A project is more like an open wiki than a standard guarded open source project.
+
+
+Rules
+
+
+
+
+There are a few basic ground-rules for contributors (including the maintainer(s) of the project):
+
+
+-
+
-
+
No
+--forcepushes or modifying the Git history in any way. If you need to rebase, ensure you do it in your own repo.
+ -
+
Non-master branches, prefixed with a short name moniker (e.g.
+gav-my-feature) must be used for ongoing work.
+ -
+
All modifications must be made in a pull-request to solicit feedback from other contributors.
+
+ -
+
A pull-request must not be merged until CI has finished successfully.
+
+
+
+Merging pull requests once CI is successful:
+
+
+-
+
-
+
A pull request with no large change to logic that is an urgent fix may be merged after a non-author contributor has reviewed it well.
+
+ -
+
No PR should be merged until all reviews' comments are addressed.
+
+
+
+Reviewing pull requests:
+When reviewing a pull request, the end-goal is to suggest useful changes to the author. Reviews should finish with approval unless there are issues that would result in:
+
+
+-
+
-
+
Buggy behaviour.
+
+ -
+
Undue maintenance burden.
+
+ -
+
Breaking with house coding style.
+
+ -
+
Pessimisation (i.e. reduction of speed as measured in the projects benchmarks).
+
+ -
+
Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
+
+ -
+
Uselessness (i.e. it does not strictly add a feature or fix a known issue).
+
+
+
+Reviews may not be used as an effective veto for a PR because:
+-
+
-
+
There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix.
+
+ -
+
It does not fit well with some other contributors' longer-term vision for the project.
+
+
+
+Releases
+
+
+
+
+Declaring formal releases remains the prerogative of the project maintainer(s).
+
+
+Changes to this arrangement
+
+
+
+
+This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.
+
+
+
+ Heritage
+
+
+
+
+These contributing guidelines are modified from the "OPEN Open Source Project" guidelines for the Level project: https://github.com/Level/community/blob/master/CONTRIBUTING.md
+
+
+
+
+
+ results matching ""
+
+
+
+