feat: linting CI job

.eslintrc

@@ -0,0 +1,6 @@
+{
+  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
+  "parser": "@typescript-eslint/parser",
+  "plugins": ["@typescript-eslint"],
+  "root": true
+}

.github/pull_request_template.md

@@ -17,4 +17,4 @@
 - [ ] PR title corresponds to the body of PR (we generate changelog entries from PRs).
 - [ ] Tests for the changes have been added / updated.
 - [ ] Documentation comments have been added / updated.
-- [ ] Code has been formatted via `zk fmt` and `zk lint`.
+- [ ] Code has been formatted via `yarn prettier:write` and `yarn lint:fix`.

.github/workflows/ci.yaml

@@ -18,12 +18,9 @@ jobs:
       - name: Install dependencies
         run: yarn
 
-      - name: Build Solidity artifacts
+      - name: Build artifacts
         run: yarn build
 
-      - name: Build yul artifacts
-        run: yarn preprocess && yarn compile-yul
-
       - name: Create cache
         uses: actions/cache/save@v3
         with:
@@ -36,8 +33,27 @@ jobs:
             contracts/precompiles/artifacts
             bootloader/build
 
+  lint:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout the repository
+        uses: actions/checkout@v3
+
+      - name: Use Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 18.18.0
+          cache: yarn
+
+      - name: Install dependencies
+        run: yarn
+
+      - name: Run lint
+        run: yarn lint
+
   test:
-    needs: [build]
+    needs: [build, lint]
     runs-on: ubuntu-latest
 
     steps:
@@ -69,13 +85,11 @@ jobs:
             contracts/precompiles/artifacts
             bootloader/build
 
-
       - name: Run tests
         run: yarn test
 
-
   test_bootloader:
-    needs: [build]
+    needs: [build, lint]
     runs-on: ubuntu-latest
 
     steps:
@@ -100,6 +114,5 @@ jobs:
             contracts/precompiles/artifacts
             bootloader/build
 
-
       - name: Run bootloader tests
         run: "cd bootloader/test_infra && cargo run"

.markdownlintignore

@@ -0,0 +1 @@
+node_modules

.markdownlintrc

@@ -0,0 +1,9 @@
+{
+  "default": true,
+  "header-increment": false,
+  "no-duplicate-header": false,
+  "no-inline-html": false,
+  "line-length": false,
+  "fenced-code-language": false,
+  "no-multiple-blanks": false
+}

.prettierignore

@@ -0,0 +1 @@
+contracts/openzeppelin

.prettierrc

@@ -0,0 +1,63 @@
+{
+  "plugins": ["prettier-plugin-solidity"],
+  "overrides": [
+    {
+      "files": "*.js",
+      "options": {
+        "tabWidth": 4,
+        "printWidth": 120,
+        "singleQuote": true,
+        "trailingComma": "none",
+        "bracketSpacing": true
+      }
+    },
+    {
+      "files": "*.json",
+      "options": {
+        "tabWidth": 2,
+        "printWidth": 120,
+        "bracketSpacing": true
+      }
+    },
+    {
+      "files": "*.md",
+      "options": {
+        "tabWidth": 2,
+        "printWidth": 120,
+        "parser": "markdown",
+        "singleQuote": true,
+        "trailingComma": "none",
+        "bracketSpacing": true,
+        "proseWrap": "always"
+      }
+    },
+    {
+      "files": "*.sol",
+      "options": {
+        "printWidth": 120,
+        "tabWidth": 4,
+        "useTabs": false,
+        "singleQuote": false,
+        "bracketSpacing": false
+      }
+    },
+    {
+      "files": "*.ts",
+      "options": {
+        "tabWidth": 4,
+        "printWidth": 120,
+        "parser": "typescript",
+        "singleQuote": true,
+        "trailingComma": "none",
+        "bracketSpacing": true
+      }
+    },
+    {
+      "files": "*.yaml",
+      "options": {
+        "tabWidth": 2,
+        "printWidth": 120
+      }
+    }
+  ]
+}

.solhint.json

@@ -0,0 +1,20 @@
+{
+  "extends": "solhint:recommended",
+  "rules": {
+    "state-visibility": "off",
+    "func-visibility": ["warn", { "ignoreConstructors": true }],
+    "var-name-mixedcase": "off",
+    "avoid-call-value": "off",
+    "no-empty-blocks": "off",
+    "not-rely-on-time": "off",
+    "avoid-low-level-calls": "off",
+    "no-inline-assembly": "off",
+    "const-name-snakecase": "off",
+    "no-complex-fallback": "off",
+    "reason-string": "off",
+    "func-name-mixedcase": "off",
+    "no-unused-vars": "off",
+    "max-states-count": "off",
+    "compiler-version": ["warn", "^0.8.0"]
+  }
+}

.solhintignore

@@ -0,0 +1 @@
+contracts/openzeppelin

README.md

@@ -10,57 +10,65 @@ write smart contracts in C++, Rust and other popular languages.
 ## system-contracts
 
 To keep the zero-knowledge circuits as simple as possible and enable simple extensions, we created the system contracts.
-These are privileged special-purpose contracts that instantiate some recurring actions on the protocol level. Some of the
-most commonly used contracts:
+These are privileged special-purpose contracts that instantiate some recurring actions on the protocol level. Some of
+the most commonly used contracts:
 
-`ContractDeployer` This contract is used to deploy new smart contracts. Its job is to make sure that the bytecode for each deployed 
-contract is known. This contract also defines the derivation address. Whenever a contract is deployed, a ContractDeployed 
-event is emitted.
+`ContractDeployer` This contract is used to deploy new smart contracts. Its job is to make sure that the bytecode for
+each deployed contract is known. This contract also defines the derivation address. Whenever a contract is deployed, a
+ContractDeployed event is emitted.
 
-`L1Messenger` This contract is used to send messages from zkSync to Ethereum. For each message sent, the L1MessageSent event is emitted.
+`L1Messenger` This contract is used to send messages from zkSync to Ethereum. For each message sent, the L1MessageSent
+event is emitted.
 
-`NonceHolder` This contract stores account nonces. The account nonces are stored in a single place for efficiency (the tx nonce and
-the deployment nonce are stored in a single place) and also for the ease of the operator.
+`NonceHolder` This contract stores account nonces. The account nonces are stored in a single place for efficiency (the
+tx nonce and the deployment nonce are stored in a single place) and also for the ease of the operator.
 
-`Bootloader` For greater extensibility and to lower the overhead, some parts of the protocol (e.g. account abstraction rules) were
-moved to an ephemeral contract called a bootloader. 
+`Bootloader` For greater extensibility and to lower the overhead, some parts of the protocol (e.g. account abstraction
+rules) were moved to an ephemeral contract called a bootloader.
 
-We call it ephemeral because it is not physically deployed and cannot be called, but it has a formal address that is used 
-on msg.sender, when it calls other contracts.
+We call it ephemeral because it is not physically deployed and cannot be called, but it has a formal address that is
+used on msg.sender, when it calls other contracts.
 
 ## Building
 
 This repository is used as a submodule of the [zksync-2-dev](https://github.com/matter-labs/zksync-2-dev).
 
-Compile the solidity contracts: `yarn build`
-
-Run the bootloader preprocessor: `yarn preprocess`
-
-Compile the yul contracts: `yarn hardhat run ./scripts/compile-yul.ts`
+Compile the solidity and yul contracts: `yarn build`
 
 ## Update Process
 
-System contracts handle core functionalities and play a critical role in maintaining the integrity of our protocol. To ensure the highest level of security and reliability, these system contracts undergo an audit before any release.
+System contracts handle core functionalities and play a critical role in maintaining the integrity of our protocol. To
+ensure the highest level of security and reliability, these system contracts undergo an audit before any release.
 
-Here is an overview of the release process of the system contracts which is aimed to preserve agility and clarity on the order of the upgrades:
+Here is an overview of the release process of the system contracts which is aimed to preserve agility and clarity on the
+order of the upgrades:
 
 ### `main` branch
 
-The `main` branch contains the latest code that is ready to be deployed into production. It reflects the most stable and audited version of the protocol.
+The `main` branch contains the latest code that is ready to be deployed into production. It reflects the most stable and
+audited version of the protocol.
 
-### `dev` branch 
+### `dev` branch
 
-The `dev` branch is for active development & the latest code changes. Whenever a new PR with system contract changes is created it should be based on the `dev` branch.
+The `dev` branch is for active development & the latest code changes. Whenever a new PR with system contract changes is
+created it should be based on the `dev` branch.
 
-### Creating a new release:
+### Creating a new release
 
-Whenever a new release is planned, a new branch named `release-vX-<name>` should be created off the `dev` branch, where `X` represents the release version, and `<name>` is a short descriptive name for the release. The PR with the new release should point to either the `main` branch or to the release branch with a lower version (in case the previous branch has not been merged into `main` for some reason).
+Whenever a new release is planned, a new branch named `release-vX-<name>` should be created off the `dev` branch, where
+`X` represents the release version, and `<name>` is a short descriptive name for the release. The PR with the new
+release should point to either the `main` branch or to the release branch with a lower version (in case the previous
+branch has not been merged into `main` for some reason).
 
-Once the audit for the release branch is complete and all the fixes from the audit are applied, we need to merge the new changes into the `dev` branch. Once the release is final and merged into the `main` branch, the `main` branch should be merged back into the `dev` branch to keep it up-to-date.
+Once the audit for the release branch is complete and all the fixes from the audit are applied, we need to merge the new
+changes into the `dev` branch. Once the release is final and merged into the `main` branch, the `main` branch should be
+merged back into the `dev` branch to keep it up-to-date.
 
-### Updating Unaudited Code:
+### Updating Unaudited Code
 
-Since scripts, READMEs, etc., are code that is not subject to audits, these are to be merged directly into the `main` branch. The rest of the release branches as well as the `dev` branch should merge `main` to synchronize with these changes.
+Since scripts, READMEs, etc., are code that is not subject to audits, these are to be merged directly into the `main`
+branch. The rest of the release branches as well as the `dev` branch should merge `main` to synchronize with these
+changes.
 
 ## License
 

SystemConfig.json

@@ -14,4 +14,4 @@
   "KECCAK_ROUND_COST_GAS": 40,
   "SHA256_ROUND_COST_GAS": 7,
   "ECRECOVER_COST_GAS": 1112
-}
+}

bootloader/test_infra/README.md

@@ -2,14 +2,14 @@
 
 This crate allows you to run the unittests against the bootloader code.
 
-You should put your tests in ../tests/bootloader/bootloader_test.yul, then compile the yul with:
+You should put your tests in `../tests/bootloader/bootloader_test.yul`, then compile the yul with:
 
 ```shell
-yarn build && yarn preprocess && yarn compile-yul
+yarn build
 ```
 
 And afterwards run the testing infrastructure:
 
 ```shell
 cargo run
-```
+```