intellij-postfix-templates: hundreds of editable expansion templates for IDEA

What a postfix template is, and why the built-in feature is not enough

Custom Postfix Templates is an IntelliJ IDEA plugin that allows you to define your own custom postfix completion templates, and it supports Java, Scala, SQL, PHP, Go, Groovy, Python, LaTeX and Kotlin, with untyped templates for Dart, JavaScript and Rust.

The comparison the documentation opens with is with IDEA's own feature, and the honest version of it is that IDEA got this in 2018 and the plugin is more functional. Since IDEA 2018 you are able to define your own postfix templates in the settings UI, under Editor, General, Postfix Templates, but the documentation calls that a fairly new feature and less functional than this plugin.

The advantages it lists are worth reading individually, because they are the design goals.

You can define different template rules for the same template name, so .toList should behave differently for arrays and for sets. You can use template variables, in the form $varName$, which are filled in by the user while applying the template. You can use live template macros to fill some of those variables automatically, in the form $var:suggestVariableName()$, and you can define default values. You can restrict the availability of templates or template rules to the availability of certain classes or libraries, so expanding "test".val to val s = "test" only when Lombok is on the classpath. And it allows you to use static imports instead of class imports, so array.toList expands to asList(array) rather than Arrays.asList(array) if you add [USE_STATIC_IMPORTS] to the rule.

The last point is the one that makes this more than a convenience. Static import expansion is a matter of project style, and the built-in feature cannot express it, so in a codebase that uses static imports everywhere the plugin's templates are simply the correct ones.

The bundle is more than 500 editable postfix templates with more than 700 template rules, and the examples given are string.toInt expanding to Integer.parse(string), array.toList expanding to Arrays.asList(array), file.lines expanding to Files.readAllLines(file.toPath(), Charset.forName("UTF-8")), and file.getName().val expanding to final String name = file.getName();.

The template format, and why being plain text is the point

The format of a template definition is deliberately boring, and that is a feature.

A file may contain multiple template definitions of the form:

.TEMPLATE_NAME : TEMPLATE_DESCRIPTION
    TEMPLATE_RULE1
    TEMPLATE_RULE2
    ...

Each definition consists of a template name, a template description and an arbitrary number of template rules. The name is the key in the code completion and the description is the hint shown in the popup. The rules define on which types the template can be applied and how the application is performed.

A simple template rule is a type and a replacement:

    MATCHING_TYPE  →  TEMPLATE_CODE

The matching type defines the type the template applies to, and the template code defines how the expression is replaced. The options for the matching type differ by language, and for Java the list is long enough to be a specification of its own. There is ANY for any expression, VOID for any void expression, NON_VOID, ARRAY, BOOLEAN for boxed or unboxed boolean expressions, ITERABLE_OR_ARRAY, NOT_PRIMITIVE, NUMBER for boxed or unboxed numbers, and the boxed primitive types BYTE, SHORT, CHAR, INT, LONG, FLOAT and DOUBLE.

The reason the text format matters is stated in the feature list as the last advantage: the text based format for defining your templates allows you to easily share them via copy and paste. A rule file is something you can put in a chat message, paste into a code review, or commit to a shared repository, and a reviewer can read what a template does without opening the IDE. That is not true of a configuration stored in IDEA's own format, and it is the single feature that most makes this plugin worth using even in a team that mostly relies on the built-in templates.

The plugin comes with a predefined set of templates for Java and Scala that can be applied immediately. Writing "1".toInt in a Java file and pressing Ctrl+SPACE if the popup does not appear shows the completion, and selecting .toInt expands it. Pressing Alt+ENTER in the completion popup and choosing Edit '.toInt' template shows the definition.

Three kinds of template file, and the order they load in

The plugin distinguishes three kinds of template file, and the difference determines what you can change and when your changes take effect.

User template files are where you define your own templates and where you can override local or web template rules. Local template files are loaded from the local file system, are read-only, and are updated automatically when an IDEA project is opened. Web template files are loaded from the web, are read-only, and are updated automatically once a day.

The ordering rule is what makes this workable. Template rules are applied in a first-come-first-serve manner, so more specific rules and files should be placed above more general ones, and you reorder files in the tree by selecting them and using the up and down buttons.

That ordering is the mechanism behind overriding. The plugin ships a set of web template files providing in total more than 200 useful templates. Since web template files are read-only and are not meant to be edited by the user because of the automatic updates, you can still edit or deactivate individual templates from them. To change one, you start the template name completion with Ctrl+Space, press ALT+ENTER and select the third item, Edit .TEMPLATE_NAME template, which opens the web template file showing the definition. Because you cannot edit that file directly, you override the rule by pressing Alt+Enter and selecting Override template rule.

The override only works if your rule loads before the predefined template, which is done by adding your rule to a user template file placed above the predefined web template file in the settings. If you do not have one that loads earlier, you are offered to create one, and once you pick or create one, the rule is added to it automatically.

Deactivating is simpler: replace the right side of the rule with [SKIP].

So the whole precedence model in one line is: put your overrides in a user file at the top of the tree, and understand that anything you do not override will be replaced the next day when the web files refresh.

Editing templates in the IDE, and the language coverage

To edit the templates you press Shift+Alt+P, or go to Tools, then Custom Postfix Templates, then Edit Templates of Current Language. There you can change, remove or add new templates matching your needs. One detail catches people out: you have to save the template file explicitly, with Ctrl+S, in order to update the postfix templates in the IDE.

The language coverage is the other thing to check before you commit. The plugin supports Java, Scala, SQL, PHP, Go, Groovy, Python, LaTeX and Kotlin, and the four languages marked as untyped templates, Dart, JavaScript and Rust, are supported in a more limited way because the matching type information the plugin relies on is not available for them in the same form.

That distinction is a real limitation rather than a footnote. The whole point of the matching type rules is to know the static type of the expression you are expanding, and in a dynamically typed language there is no such thing at the point of expansion, so the rule cannot discriminate between an array and a set. In a typed language, the .toList example in the feature list works because the compiler already knows which of the two you have.

The repository layout reflects a plugin with generated content. There is src/ for the plugin code, resources/ for what the plugin ships, a dev/ directory, a gen/ directory which is presumably where the template files are generated, test/ for the tests, build.gradle.kts and settings.gradle.kts for the Gradle build, gradle.properties, the gradlew wrapper scripts, and a videos/ directory holding the screencast files the documentation links.

The licence is Apache-2.0 with a LICENSE.md at the root, the primary language is Java, and the plugin is published on the JetBrains marketplace at 9862. The last push to the repository was on 2026-10-12 and there are no GitHub releases, so the marketplace listing is where the versions are tracked.

Editorial conclusion

intellij-postfix-templates suits a Java or Scala developer who wants their own expansion vocabulary rather than the one IDEA ships, since you can scope a rule to a type, gate it on a library being present and let the user fill in variables. It does not suit you if you are happy with IDEA's built-in postfix templates, and you should know that the bundled web templates are read-only and updated daily, so your customisations have to live in a user file. Before you rely on it, note that the plugin's own version numbering is separate from the plugin repository entry at 9862, and that the text template format is the part worth stealing even if you use the built-in feature.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. xylo/intellij-postfix-templates on GitHub