I think when versioning a release using npm version, that's when the contract ABIs etc. should be built and committed to the repo (in the same commit as the version update).
I think when versioning a release using `npm version`, that's when the contract ABIs etc. should be built and committed to the repo (in the same commit as the version update).
Here's an example for how to do this: https://github.com/67P/remotestorage-module-chat-messages/blob/master/package.json#L10
version and publish are different. It's just that version can have hooks that add staged files to the same commit as the version commit itself for example.
`version` and `publish` are different. It's just that `version` can have hooks that add staged files to the same commit as the version commit itself for example.
this actually depends on the deployment of the individual contracts/apps - not only on on the code changes.
thus I think this will be difficult. we might want to automate the release of the contracts which will also result in a new npm version
this actually depends on the deployment of the individual contracts/apps - not only on on the code changes.
thus I think this will be difficult. we might want to automate the release of the contracts which will also result in a new npm version
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I think when versioning a release using
npm version, that's when the contract ABIs etc. should be built and committed to the repo (in the same commit as the version update).Here's an example for how to do this: https://github.com/67P/remotestorage-module-chat-messages/blob/master/package.json#L10
what does the script need to do? we would need to make sure that the build-json script runs before publishing to npm, right?
versionandpublishare different. It's just thatversioncan have hooks that add staged files to the same commit as the version commit itself for example.this actually depends on the deployment of the individual contracts/apps - not only on on the code changes.
thus I think this will be difficult. we might want to automate the release of the contracts which will also result in a new npm version