chore(deps): update dependency prettier-plugin-solidity to v2

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
prettier-plugin-solidity	1.0.0-dev.23 → 2.2.1

---

Release Notes

prettier-solidity/prettier-plugin-solidity (prettier-plugin-solidity)

v2.2.1

Compare Source

What's Changed

Release with @nomicfoundation/slang version 1.3.1 which adds support for solidity 0.8.31.

Full Changelog: prettier-solidity/prettier-plugin-solidity@v2.2.0...v2.2.1

v2.2.0

Compare Source

What's Changed

Format fixes

• Avoid printing an extra new line after the contract specifiers by @​Janther in #​1212
• Avoid removing intended new line after try-catch statement by @​Janther in #​1295, reported by @​niklasnatter

Behaviour changes

• Parse with latest compatible solidity version by @​fvictorio in #​1225
• Support @​nomicfoundation/slang 1.3.0 by @​Janther in #​1288

Internal changes

There has been a lot of work put into simplifying the printing flow avoiding extra steps and cleaning up the patterns in the printing functions across the codebase. There has been a noticeable improvement in the execution speed and cleaner codebase.

Development changes

• Add knip by @​fvictorio in #​1305

Full Changelog: prettier-solidity/prettier-plugin-solidity@v2.1.0...v2.2.0

v2.1.0

Compare Source

What's Changed

API Changes

• Added support for experimentalOperatorPosition. by @​Janther in #​1162
• Using Slang's language inference tool to decide what solidity version will be assumed in case no compiler option is provided. by @​Janther in #​1158 and #​1175

Format Changes

• Only break import deconstruction if the list of items is longer than 1. by @​Janther in #​1178

// Original
import { Item } from "../../../contracts/very/long/path/to/File1.sol";
import { Item1, Item2 } from "../../../contracts/very/long/path/to/File2.sol";

// version 2.0.0
import {
    Item
} from "../../../contracts/very/long/path/to/File.sol";
import {
    Item1,
    Item2
} from "../../../contracts/very/long/path/to/File2.sol";

// version 2.1.0
import { Item } from "../../../contracts/very/long/path/to/File.sol";
import {
    Item1,
    Item2
} from "../../../contracts/very/long/path/to/File2.sol";

• New rules added to the grouping in a single line when possible and indentation when the line breaks on binary operations to improve readability and make operations precedence more visible. by @​Janther in #​1133

// Original
x = veryLongNameA * veryLongNameB + veryLongNameC;
x = veryLongNameA + veryLongNameB * veryLongNameC;

x = veryVeryLongNameA * veryVeryLongNameB + veryVeryLongNameC;
x = veryVeryLongNameA + veryVeryLongNameB * veryVeryLongNameC;

// version 2.0.0
x =
    veryLongNameA *
    veryLongNameB +
    veryLongNameC;
x =
    veryLongNameA +
    veryLongNameB *
    veryLongNameC;

x =
    veryVeryLongNameA *
    veryVeryLongNameB +
    veryVeryLongNameC;
x =
    veryVeryLongNameA +
    veryVeryLongNameB *
    veryVeryLongNameC;

// version 2.1.0
x =
    veryLongNameA * veryLongNameB +
    veryLongNameC;
x =
    veryLongNameA +
    veryLongNameB * veryLongNameC;

x =
    veryVeryLongNameA *
        veryVeryLongNameB +
    veryVeryLongNameC;
x =
    veryVeryLongNameA +
    veryVeryLongNameB *
        veryVeryLongNameC;

• Fixed a format issue where a small operand would be left in a new line if the right operand breaks in an assignment. by @​Janther in #​1161

// Original
a = veryVeryVeryVeryVeryLongFunctionCalledA(veryVeryVeryVeryVeryLongArgumentCalledB) ** c;

// version 2.0.0
a =
    veryVeryVeryVeryVeryLongFunctionCalledA(
        veryVeryVeryVeryVeryLongVariableCalledB
    ) **
    c;

// version 2.1.0
a =
    veryVeryVeryVeryVeryLongFunctionCalledA(
        veryVeryVeryVeryVeryLongVariableCalledB
    ) ** c;

• Added parentheses on consecutive equality operators to improve readability in operation precedence. by @​Janther in #​1132

// Original
a == b == c;
a != b == c;

// version 2.0.0
a == b == c;
a != b == c;

// version 2.1.0
(a == b) == c;
(a != b) == c;

• Fixed bug in the last comment in a struct definition. by @​Janther in #​1181

// Original
struct A {
    uint a;
    uint b;
    // uint c; // commented because I decided to test something
}

// version 2.0.0
struct A {
    uint a;
    uint b;
}
// uint c; // commented because I decided to test something

// version 2.1.0
struct A {
    uint a;
    uint b;
    // uint c; // commented because I decided to test something
}

Breaking Changes

• Dropped support for node 18 by @​Janther in #​1157

New Contributors

• @​Radovenchyk made their first contribution in #​1144

Full Changelog: prettier-solidity/prettier-plugin-solidity@v2.0.0...v2.1.0

v2.0.0

Compare Source

This is a new major version of Prettier Plugin Solidity.

The changes from v1 are minimal, but there are a couple of breaking changes.

The plugin now uses Slang as the parser by default. Slang is a more powerful and correct parser that improves formatting in many edge cases—especially when comments are involved.

If you had the parser explicitly set in your .prettierrc (e.g., "parser": "solidity-parse"), you'll need to update it to:

"parser": "slang"

If you don't have the parser option set in your config, no action is needed.

The old ANTLR-based parser is still supported in v2, but it's deprecated and will be removed in the next major version.

v1.4.3

Compare Source

What's Changed

• Adding support for storage layout by @​Janther in #​1117

Full Changelog: prettier-solidity/prettier-plugin-solidity@v1.4.2...v1.4.3

v1.4.2

Compare Source

New features

• Add support for transient keyword by @​Janther in #​1079

Format changes

• Don't re-write import * as ... from ... by @​Janther in #​1083

// Original
import * as SomeSymbol from "AnotherFile.sol";

// [email protected]
import "AnotherFile.sol" as SomeSymbol;

// [email protected]
import * as SomeSymbol from "AnotherFile.sol";

Breaking changes

• Dropping support for node 16 by @​Janther in #​1082

Full Changelog: prettier-solidity/prettier-plugin-solidity@v1.4.1...v1.4.2

v1.4.1

Compare Source

@​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

Compare Source

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

Compare Source

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

v1.3.0

Compare Source

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

Compare Source

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

Compare Source

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

v1.1.2

Compare Source

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

Compare Source

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)

v1.1.0

Compare Source

With this version, we are releasing a standalone build (#​727).
It follows the same patterns Prettier uses for their internal plugins such as UMD.
Hopefully this will make integration for projects based on the browser easy and will be automatically shipped on each release to http://unpkg.com/prettier-plugin-solidity@latest.

We also took care of a small bug that would print an extra line when formatting solidity code within a markdown code block (#​765).

v1.0.0

Compare Source

We are happy to release the first stable version of Prettier Solidity! 🎉 🎉

What does this mean for you as a user? Semantic versioning doesn't make a lot of sense for a formatter, so it's hard to give hard rules about what will be the meaning of future versions. But we'll try to follow these guidelines:

• We won't make big formatting changes within the same major version. For example, you shouldn't get all your function signatures changed just because you upgraded to, say, v1.1.0.
• We won't remove any option within the same major version.
• We'll use patch versions (e.g., moving from 1.2.3 to 1.2.4) for bug fixes and very minor formatting changes.
• We'll use minor versions (e.g., moving from 1.2.3 to 1.3.0) for new language constructs, new options (if any) and somewhat bigger formatting changes.

What separates a "very minor formatting change" from a "bigger one" is hard to define precisely, of course, so some of these decisions will be very subjective, but we'll try to do our best.

Thanks for using our plugin and remember to star the repo! ⭐

v1.0.0-rc.1

Compare Source

This is our first release candidate for a stable v1.0.0!

This version includes some significant changes:

• We removed the explicitTypes option, since we believe that this belongs to a linter. The behavior now is the same one that you would get if using explicitTypes: "preserve", meaning that we'll never convert an uint to an uint256 or vice versa.
• In previous versions, the parameters of a function definition would always be split if there were more than two of them. Starting now, we only split them if the line doesn't fit in line-width. Plus, the way this works is that first the parameters are split, then the modifiers (if they also don't fit in a single line), and finally the return parameters (also only if they don't fit).
• The exponentiation operator (**) now has spaces around it. This is more consistent with other operators, and it looks better for long variable names (that is, base ** decimals is better than base**decimals). We do know that this is not as nice for some cases (2 ** 10), but we are erring on the side of consistency and a better worst-case scenario.

As an example, a function like this:

contract Foo {
  function f(uint x, uint y, uint z) mod1 mod2 { x**y**z; }
}

would be formatted in the previous version like this:

contract Foo {
    function f(
        uint256 x,
        uint256 y,
        uint256 z
    ) mod1 mod2 {
        x**y**z;
    }
}

and now it will be formatted like this:

contract Foo {
    function f(uint x, uint y, uint z) mod1 mod2 {
        x ** y ** z;
    }
}

Please upgrade to the latest version and let us if you find any issues!

v1.0.0-dev.24

Compare Source

---

Configuration

📅 Schedule: Branch creation - "on the first day of the week" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.