prettier-plugin-solidity, a formatter for Solidity that works with Prettier

What the plugin does and the version split

prettier-plugin-solidity is a Prettier plugin for automatically formatting Solidity code, and the way it is packaged is the point. A Solidity contract ends up formatted by the same tool, with the same config file and the same editor integration, as the TypeScript and JavaScript in the same repository.

The README carries a note that it is written for the new major version of the plugin, that the differences from v1 are minimal but there are some breaking changes, and that a migration guide exists for moving from v1. The previous version lives on a separate v1 branch, so the two versions coexist in the repository rather than the old one being deleted.

The parser is named in the browser example, where the format call passes parser: 'slang'. Slang is the Solidity parser, and using it rather than a hand-rolled parser is what makes the plugin's output match what the compiler and the tooling ecosystem consider canonical.

One constraint is stated plainly and matters for a lint check: Prettier Solidity only works with valid code. If there is a syntax error, nothing will be done and a parser error will be thrown. So this is a formatter, not a linter, and it will not tell you what is wrong with a broken contract beyond the fact that it could not parse it.

The licence is MIT, the language is TypeScript, and the release history shows active work: v2.3.1 in March 2026, v2.4.0 in August and v2.4.1 days later, with the last push on 2026-10-19.

Setting it up in Node and in CI

The Node setup is two steps, and both the formatter and the plugin are dev dependencies:

npm install --save-dev prettier prettier-plugin-solidity

Then you run Prettier over your contracts:

npx prettier --write --plugin=prettier-plugin-solidity 'contracts/**/*.sol'

The plugin argument is passed on the command line rather than configured in the prettier config, which is the older style of plugin registration and still works.

The README then shows the two npm script forms that most projects end up with. A format script writes the files:

"prettier": "prettier --write --plugin=prettier-plugin-solidity 'contracts/**/*.sol'"

and a lint script checks without writing, using the --list-different flag:

"lint": "prettier --list-different --plugin=prettier-plugin-solidity 'contracts/**/*.sol'"

That pair is the standard split. The write script is what a developer runs to tidy their work, and the check script is what runs in continuous integration and fails the build if a file is not formatted. The reason to keep them separate is that a formatting check that also rewrites files is not a check, and a team that only ever runs the write script never finds out that a colleague committed unformatted code.

The glob quoted with single quotes is worth keeping. Prettier expands the glob itself rather than letting the shell do it, and the quotes stop a shell with a different globbing behaviour from passing the wrong set of files.

Since the plugin lives in the same Prettier ecosystem as the rest of the project, the .prettierrc file governs Solidity too, including print width, tab width, semicolons and the rest. That is the practical convenience: there is one formatting policy for the whole repository rather than one for Solidity and one for everything else.

Running it in the browser

The browser use case exists for anyone building a web tool that formats Solidity on the fly, such as a documentation site with a live editor. The requirement is that you load Prettier's standalone bundle before loading the build provided by this package, because the plugin registers itself into a global object that Prettier's standalone build populates.

The README explains the mechanism. Prettier's unpkg field points to https://unpkg.com/prettier/standalone.js, and in the same way this plugin points to https://unpkg.com/prettier-plugin-solidity/dist/standalone.js. Once both are loaded you have the globals prettier and prettierPlugins.

The example shows the whole flow:

<script type="module">
  await import('https://unpkg.com/prettier@latest');
  await import('https://unpkg.com/prettier-plugin-solidity@latest');

  // The global variables `prettier` and `prettierPlugins` are automatically
  // created and populated by importing each module.

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

  const originalCode = 'contract Foo    {}';
  const formattedCode = await format(originalCode);
</script>

The plugin follows Prettier's own strategy for populating the plugins object, so other plugins can be loaded the same way, for instance the markdown plugin at https://unpkg.com/prettier@latest/plugins/markdown.js, and Prettier will then have access to multiple parsers.

The README also covers the case where you are creating your own browser package and want to import the standalone files directly rather than going through the global, with an example that begins with importing prettier from the standalone entry point.

One caveat about this whole approach comes from the dependency itself rather than the plugin: loading both bundles from a CDN at the latest version means the version of Prettier and the version of the plugin are decided by whoever wrote the page, and a mismatch between them is a runtime failure rather than an install-time one.

Practical checks before you adopt it

Three things are worth doing before you make this part of your build, and all three are cheap.

First, run the check mode over your existing contracts and read the diff. Not the count of changed files, the diff. Prettier is opinionated, and for Solidity that shows up in how it lays out long function signatures, how it wraps modifier lists, and where it puts comments that sit between parameters. A repository with a lot of NatSpec documentation and a lot of commented-out code is where the churn will be highest, and you want to see it before the whole team sees it in a pull request.

Second, decide what happens to the files you do not want reformatted. Prettier has a .prettierignore, and the same one that excludes your generated TypeScript can exclude the generated Solidity, which matters because Solidity has several code generators in common use. Anything a tool writes, you do not want a formatter touching, because the next run of the generator will produce a diff and you will get a merge conflict between the tool and the formatter.

Third, pin the versions. The plugin, Prettier itself and the Solidity compiler all move, and a formatter upgrade that changes the output for every file in the repository is a large diff to review. Pinning the Prettier version in your lockfile and reviewing the plugin's changelog before bumping it keeps that under your control.

There is also the question of where the format check runs. If your CI runs it as part of a broader lint job, a formatting failure is mixed in with real lint failures, which trains people to ignore the job. A separate job that fails with a list of unformatted files is easier to act on, and the --list-different flag gives exactly that list.

And a note on the editor experience. Once the plugin is installed, the Prettier extension in your editor formats Solidity files on save, which means the format check in CI passes for anyone who has the extension. The people who do not have it are the ones who get the failing check, so it is worth mentioning the extension in the contribution guide rather than assuming it.

How it compares with the other Solidity formatters

The established alternative in the Solidity ecosystem is the formatter bundled with the Solidity compiler itself, solc with the standard-json output, or the various wrappers around it. The difference in approach is that this plugin goes through Prettier's plugin interface, which means it inherits Prettier's configuration model, its editor integrations and its ignore file handling, while a compiler-side formatter has its own options and its own integration story.

That inheritance is the whole argument. If your project already has Prettier configured for TypeScript, adding this plugin is one dev dependency and one script, and the Solidity files end up matching the surrounding code. A separate formatter means a separate config, a separate pre-commit hook and a separate editor integration, and the two will disagree about line width and indentation unless you configure them to agree.

The cost of going through Prettier is that you inherit Prettier's opinions too. Prettier is opinionated and deterministic, which is what you want from a formatter, and it does not preserve the author's line breaks or blank line choices. For Solidity specifically, that means comment placement can move, and a licence header or a NatSpec block may end up somewhere you did not put it.

The other alternatives are editor-specific formatters and the newer dedicated Solidity formatters that have appeared with support for the modern syntax. Those exist because Prettier's model does not fit every Solidity construct perfectly, and a dedicated formatter can make choices that suit the language better.

The practical guidance is to try the diff before you commit. Run the plugin in check mode over a repository with heavily commented contracts and look at what changes. If the churn is acceptable, adopt it. If comments move in ways that annoy you, the dedicated Solidity formatter is likely the better tool even though it means running two formatters in one project.

One more thing to check is the version compatibility with your Prettier version, since a Prettier major release has broken plugins before. The plugin's own release cadence is active, and the v2 line has been shipping regularly through 2026, which is a good sign.

Editorial conclusion

Adopt prettier-plugin-solidity if your project already formats with Prettier and you want Solidity in the same workflow with one configuration file. Skip it if you need to preserve comment placement exactly, since a formatter will reflow code around comments. Verify first by running it in check mode with --list-different over your contracts and reviewing the diff on a file with heavy commenting, because Prettier only formats valid code and will throw a parser error otherwise.

Frequently asked questions

Official sources

1. License: MIT
2. prettier-solidity/prettier-plugin-solidity on GitHub
3. Project website
4. README
5. Releases