v2.0.0-beta.2

Moving closer to a release candidate, this pre-release adds the following features:

• Support for @nomicfoundation/slang@0.17.0 #1043
• Infer solidity version from source code #1047

2.0.0-beta.1

This year we have been working hard on adopting Nomic Foundation's Slang as our new parser.

This allowed us to update our architecture, address issues that the ANTLR parser was blocking, have more control in the rendering of comments, and officially move our codebase to typescript.

While in beta, we will still serve the solidity-parse parser, but the plugin will now log a deprecation warning recommending using the slang-solidity parser.

To start using the new parser just replace solidity-parse with slang-solidity in the .prettierrc file.

{
  "plugins": ["prettier-plugin-solidity"],
  "overrides": [
    {
      "files": "*.sol",
      "options": {
        "parser": "slang-solidity",
        "printWidth": 80,
        "tabWidth": 4,
        "useTabs": false,
        "singleQuote": false,
        "bracketSpacing": false,
        "compiler": "0.8.26",
      }
    }
  ]
}

If a compiler version is specified, this will be used to parse all the contracts in your project. By default the compiler version will be the latest Solidity version supported by @nomicfoundation/slang. The final 2.0.0 release will infer the Solidity version from the pragma statements in each contract.

A wasm build of the @nomicfoundation/slang package is not included in this beta release. This means the beta release can currently be used in node projects and build pipelines where Rust is supported.

We are working with Nomic Foundation to include a wasm build in the final 2.0.0 release to support browser based IDEs like Remix.

import prettier from 'prettier';
import solidityPlugin from 'prettier-plugin-solidity';

async function format(code) {
  return await prettier.format(code, {
    parser: 'slang-solidity',
    compiler: '0.8.26',
    plugins: [solidityPlugin],
  });
}

const originalCode = 'contract Foo {}';
const formattedCode = format(originalCode);

We invite everyone to try this new version out and welcome reports of new issues.

v1.4.1

@pcaversaccio let us know that one of our formatting decisions was formatting an expected result so this was quickly reverted to the previous standard.

// Input
contract Comments {
    function ifElse() public {
        if (condition) {
            // ...
        } // Reason for else case
        else {
            // ...
        }
    }
}

// v1.4.0
contract Comments {
    function ifElse() public {
        if (condition) {
            // ...
        } else {
            // Reason for else case
            // ...
        }
    }
}

// v1.4.1
contract Comments {
    function ifElse() public {
        if (condition) {
            // ...
        } // Reason for else case
        else {
            // ...
        }
    }
}

v1.4.0

As we are preparing for a version 2.0.0 of this plugin there were a few tweaks in the formatting that we needed to address before proceeding forward.

Empty assembly blocks

// Input
contract Assembly {
    function assemblyEmptyBlocks() public {
        assembly {}
        assembly {
            for {} lt(x, y) {} {}
        }
    }
}

// v1.3.1
contract Assembly {
    function assemblyEmptyBlocks() public {
        assembly {

        }
        assembly {
            for {

            } lt(x, y) {

            } {

            }
        }
    }
}

// v1.4.0
contract Assembly {
    function assemblyEmptyBlocks() public {
        assembly {}
        assembly {
            for {} lt(x, y) {} {}
        }
    }
}

Assembly stack assignments

In versions of Solidity prior to v0.5.0 there was a syntax called stack assignment where the last value of the stack would be allocated to a variable. This statement is independent of what happens before it but in some cases the developer could write it in the same line as the last statement.
So far we have been formatting this in the same line as the previous statement but since in v2.0.0 we will have access to an AST much closer to the actual grammar of solidity, it makes more sense to keep it in a separate statement.

// Input
contract Assembly {
    function stackAssignment() public {
        assembly {
            4 =: y
        }
    }
}

// v1.3.1
contract Assembly {
    function assemblyEmptyBlocks() public {
        assembly {
            4 =: y
        }
    }
}

// v1.4.0
contract Assembly {
    function assemblyEmptyBlocks() public {
        assembly {
            4
            =: y
        }
    }
}

HexLiterals in multiple lines

Solidity allows to declare long HexLiterals as a list of HexLiterals separated by white space. The only reason for using this feature is to display said HexLiteral in multiple lines.

// Input
contract HexLiteral {
    bytes8 hex1 = hex'Dead' hex'Beef';
}

// v1.3.1
contract Assembly {
    bytes8 hex1 = hex'Dead' hex'Beef';
}

// v1.4.0
contract Assembly {
    bytes8 hex1 =
        hex'Dead'
        hex'Beef';
}

Modifier Definitions and Function TypeNames

These 2 cases should format in the same way a function definition does but they remained with separate behaviours.

// Input
contract ModifierDefinitions {
   modifier long() override(Foo , Bar, Baz, Very, VeryVery, VeryLong, OverrideList) { _; }
   modifier threeParams(uint a, uint b, uint c) {}
}

// v1.3.1
contract ModifierDefinitions {
   modifier long()
       override(
           Foo,
           Bar,
           Baz,
           Very,
           VeryVery,
           VeryLong,
           OverrideList
       ) {
       _;
   }
   modifier threeParams(
       uint a,
       uint b,
       uint c
   ) {}
}

// v1.4.0
contract ModifierDefinitions {
   modifier long()
       override(
           Foo,
           Bar,
           Baz,
           Very,
           VeryVery,
           VeryLong,
           OverrideList
       )
   {
       _;
   }
   modifier threeParams(uint a, uint b, uint c) {}
}

// Input
contract FunctionTypeNames {
   struct StructWithFunctionTypes {
       function(bytes32, bytes32, bytes32, bytes32, bytes32, bytes32) internal view[] d;
   }
}

// v1.3.1
contract FunctionTypeNames {
   struct StructWithFunctionTypes {
       function(bytes32, bytes32, bytes32, bytes32, bytes32, bytes32)
           internal
           view[] d;
   }
}

// v1.4.0
contract FunctionTypeNames {
   struct StructWithFunctionTypes {
       function(
           bytes32,
           bytes32,
           bytes32,
           bytes32,
           bytes32,
           bytes32
       ) internal view[] d;
   }
}

There are no comments for the else keyword

As we moved into v2.0.0 we got to review many of the formatting prettier inspired us that were in the backlog.
This particular decision had already been changed prettier and we base our work on old code released by prettier. @pcaversaccio very diligently let us notice that this could not be reproduced in prettier, therefore it was quickly reverted in v1.4.1

// Input
contract Comments {
    function ifElse() public {
        if (condition) {
            // ...
        } // Reason for else case
        else {
            // ...
        }
    }
}

// v1.3.1
contract Comments {
    function ifElse() public {
        if (condition) {
            // ...
        } // Reason for else case
        else {
            // ...
        }
    }
}

// v1.4.0
contract Comments {
    function ifElse() public {
        if (condition) {
            // ...
        } else {
            // Reason for else case
            // ...
        }
    }
}

v1.3.1

Needed to put a specific experimentalTernaries behaviour behind a feature flag. (thanks @pcaversaccio)

v1.3.0

This version ships with 2 substantial changes.

1. The parser had a great improvement in size package making our bundled size go from 773.5 KB to 417 KB and 90 KB gzipped, making our support for browser more impactful. (#967)
2. We embraced prettier's ternaries formatting improvements and support the new option externalTernaries, so we invite people to start experimenting with it and give us some feedback. (#953)

v1.2.0

A few improvements on this release:

• Dropped support for node 14 (#887)
• Migrated the whole codebase to ESM (#894)
  • The bundled version now has the .cjs extension
• Improved the bundled file to better support projects targeting browsers (#943 thanks to @folego and electric_gary on Telegram)
  • Projects can easily import from prettier-plugin-solidity/standalone
• Added support for negative e notation 1000e-2 (solidity-parser/parser#95)
• Full support of file level event definitions, introduced with solidity 0.8.22 (solidity-parser/parser#97)

A few tweaks in the code and refactor for simplicity and efficiency.

v1.1.3

This version adds support for user-defined operators, a feature introduced in Solidity 0.8.19.

v1.1.2

This version adds support for named parameters in mappings, introduced in Solidity 0.8.18. This means you can add names to your mappings parameters:

mapping(address account => uint balance) balanceOf; 

and Prettier Solidity will format it correctly.

Thanks to @zemse for working on this!

v1.1.1

With this version we started supporting prettier V3 which at the moment it's in their 3.0.0-alpha.4 version. (#757)

Some internal tweaks and removed some dependencies that were no longer used. (thanks to @frangio for noticing #780)