This project demonstrates an advanced Hardhat use case, integrating other tools commonly used alongside Hardhat in the ecosystem.
The project comes with a sample contract, a test for that contract, a sample script that deploys that contract, and an example of a task implementation, which simply lists the available accounts. It also comes with a variety of other tools, preconfigured to work with the project code.
Try running some of the following tasks:
npx hardhat accounts
npx hardhat compile
npx hardhat clean
npx hardhat test
npx hardhat node
npx hardhat help
REPORT_GAS=true npx hardhat test
npx hardhat coverage
npx hardhat run scripts/deploy.js
node scripts/deploy.js
npx eslint '**/*.js'
npx eslint '**/*.js' --fix
npx prettier '**/*.{json,sol,md}' --check
npx prettier '**/*.{json,sol,md}' --write
npx solhint 'contracts/**/*.sol'
npx solhint 'contracts/**/*.sol' --fix
To try out Etherscan verification, you first need to deploy a contract to an Ethereum network that's supported by Etherscan, such as Ropsten.
In this project, copy the .env.example file to a file named .env, and then edit it to fill in the details. Enter your Etherscan API key, your Ropsten node URL (eg from Alchemy), and the private key of the account which will send the deployment transaction. With a valid .env file in place, first deploy your contract:
hardhat run --network ropsten scripts/deploy.js
Then, copy the deployment address and paste it in to replace DEPLOYED_CONTRACT_ADDRESS
in this command:
npx hardhat verify --network ropsten DEPLOYED_CONTRACT_ADDRESS "Hello, Hardhat!"
A commit message consists of a header, a body and a footer, separated by a blank line.
<type>(<scope>): <subject>
// BLANK LINE
<body>
// BLANK LINE
<footer>
The Header is required, and the Body and Footer can be omitted. Any line of the commit message cannot be longer 100 characters.
The message header is a single line that contains succinct description of the change; containing a type, an optional scope and a subject.
Type Indicates the type of commit. Only the following seven identifiers are allowed.
- feat: new feature
- fix: bug fix
- docs: documentation
- style: formatting(Changes that do not affect code execution)
- refactor: scrap all the old code
- test: when adding missing tests
- chore: changes to the ancillary tools
Scope is used to specify the scope of the commit impact, such as the data layer, control layer, view layer, and so on, depending on the project.
Subject is a short description of the commit purpose, no more than 50 characters long.
- Start with a verb and use the present first-person tense such as 'change' rather than 'changed' or 'changes';
- The first letter should be lowercase;
- No dot (.) at the end.
The Body section is a detailed description of the commit, broken into multiple lines.
There are two caveats:
- start with a verb and use the present first-person tense such as 'change' rather than 'changed' or 'changes';
- includes motivation for the change and contrasts with previous behavior.
The Footer section is only used in two cases.
All breaking changes have to be mentioned as a breaking change block in the footer, which should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then the description of the change, justification and migration notes.
BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
myBind: 'bind',
myExpression: 'expression',
myEval: 'evaluate',
myAccessor: 'accessor'
}
After:
scope: {
myAttr: '@',
myBind: '@',
myExpression: '&',
// myEval - usually not useful, but in cases where the expression is assignable, you can use '='
myAccessor: '=' // in directive's template change myAccessor() to myAccessor
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
Closed bugs should be listed on a separate line in the footer prefixed with "Closes" keyword like this:
Closes #234
or in case of multiple issues:
Closes #123, #245, #992
feat($browser): onUrlChange event (popstate/hashchange/polling)
Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available
Breaks $browser.onHashChange, which was removed (use onUrlChange instead)
Commitizen is a tool for writing qualified Commit messages.
Installing the command line tool
npm install -g commitizen
Then, in the project directory, run the following command to support Angular's Commit Message format.
commitizen init cz-conventional-changelog --save --save-exact
Use git cz
instead of git commit
. At this point, options are presented to generate a Commit message that matches the format.