The Good Tech Companies - I Just Wanted Code Templates, but I Ended Up Writing a WebStorm Plugin

Episode Date: January 28, 2026

This story was originally published on HackerNoon at: https://hackernoon.com/i-just-wanted-code-templates-but-i-ended-up-writing-a-webstorm-plugin. Discover how a developer transformed monorepo boilerplate frustration into a custom WebStorm plugin. Check more stories related to programming at: https://hackernoon.com/c/programming. You can also check exclusive content about #kotlin, #webstorm, #plugin-development, #kotlin-development, #monorepo, #code-generation, #i18n-navigation, #good-company, and more. This story was written by: @socialdiscoverygroup. Learn more about this writer by checking @socialdiscoverygroup's about page, and for more stories, please visit hackernoon.com. Aleksei Kovrigin is a Software Engineer at Social Discovery Group. He wanted to create a tool to help Frontend developers with code style. He decided to use WebStorm's File and Code Templates feature to create hierarchies.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. I just wanted code templates, but I ended up writing a WebStorm plugin. By Social Discovery Group, working in a large monorepo with a long-term project has its oddities. Every time I started a new feature, I turned from a developer into a file manager. Create a folder, organize files, write boilerplate code, copy imports from a neighbor file, and don't forget to clean up the mess. Each action only takes a minute, but over a week, it really adds up. Most importantly, this routine drains energy. Instead of keeping my focus on business logic, I wasted my attention on mechanical copy pasting and checking

paths. At first, I wanted to solve the problem the easy way by configuring standard file and code templates in WebStorm. But I quickly hit a wall. Templates can't handle paths flexibly, they can't properly convert to inside the code, and sharing settings with the whole team is a nightmare. The tool that was supposed to help started to annoy me. Then I thought, what if I stopped configuring the I'd and start programming it? This thought led me to create my own plugin. And you know what? It wasn't as scary as people say.

I didn't have to learn Java or read manuals for years. It turned out that for a front-end developer, modern Kotlin looks suspiciously like TypeScript. In this article, I'll share how I went from a simple desire to make a Templetato building a full-fledged tool and why you should stop tolerating a bad developer. experience, DX. The problem, infinite copy paste and blind navigation dozens of developers work on our project in a single repository. This imposes strict restrictions on code style. For example, any React component is always separated into a presentation part and logic and styles lie nearby in a separate file. Forgot to wrap the component in? Props are not destructured in the first line? You won't pass

code review. The trap of simple solutions. Why file? templates failed when I finally got fed up with the routine, I dug into the settings. The ideal scenario in my head looked like this. One click, and I generate the whole bunch of files, component, view, styles. It turned out WebStorm can do this. Deep in the settings, there is a feature to create not just files, but hierarchies via child templates. I quickly set up a configuration. 1.

Parent template, standard TSX component, name, extension, file name, dollar, name index code one child files via button view view t sx file name dollar name view extension tsx code styles styles module less file name dollar name styles module extension less code Vuala, Victory, I choose the template, enter the folder name and file name, and T-H-E-I'd creates the folder and organizes the files itself. I felt like an automation genius, for exactly two days. The euphoria vanished when I faced the harsh reality of Apache Velocity, the IDE template engine, naming problems. Converting to for the import paths and back to for constants inside the template is painful. You have to write terrible macros that break constantly. Limited access

to file structure. Templates can only create files relative to where you clicked. If I need to create files in folders of different modules at the same time, templates are powerless. Team synchronization. How do I share these settings? Export settings to zip and import, but don't mix up the checkboxes. This doesn't work in a team of 20 people. Fragility. The final blow was a WebStorm update. After another IDE update, my configured child templates simply disappeared. Why not AI? A fair question. Why write code by hand in the age of AI? Why not let GitHub copilot or JetBrains AI create the files? I actively use AI assistance in my work, but for infrastructure tasks, they lose for three reasons. Determinism. AI is a probabilistic model. It might generate the correct

file structure nine times out of 10. But on the 10th time, it will hallucinate, an extra import or mix up the folder. With a strict style guide, I need a tool I can trust 100, not when I have to double check. A plug-in doesn't think, or guess, it follows a strict algorithm. Context and speed. To make AI create a complex structure in different modules, I need to write a detailed prompt, create component X in the domain, then the implementation in web, use these paths. This takes longer than right-clicking.

Plus, AI doesn't always see the full depth of the Monorepo the way PSI, the I'd index, does. Standards. it's hard to force 20 developers to use the exact same prompt. But it's easy to give them one button that guarantees the same result for everyone. Maybe write a plugin? When it became clear that standard templates wouldn't cut it, there was only one path left, to write my own tool. The idea of creating a custom-eyed plugin was Intimmy dating at first.

In the front-end world, we tend to think Intel EJ development is reserved for hardcore Java engineers. Even the Jed Brains documentation warns you right away that, you probably don't need this, offering alternatives, like live plugin. It basically tells you, go write scripts, don't get into this mess. Honestly, I was scared of diving into an unfamiliar stack. I'm used to TS, NPM, and Webpack, and here I saw Gradle, JVM, and a complex SDK. But the desire to automate the routine was stronger than the fear. Quick start. Plug-in template my first pleasant surprise was the IntelliJ Platform plugin template from JetBrains. This is a ready-made repository template that solves the blank page problem.

You don't need to manually configure the build, write manifests, or figure out CI, CD. You just clone the repo, and you are ready to go. You have a working Hello World, configured Gradle and GitHub actions. This saved me days, maybe weeks. Kotlin is just like TypeScript. Well, almost my second fear was the language. Plugins are written in Java or Kotlin. For someone who writes modern typescript, the transition to Kotlin was surprisingly smooth.

The syntax is very similar, the same instead of. Lambda's in higher order functions work just the same. Strict typing, which we are used to in TS, works even more reliably here. Basically, if you are comfortable with TypeScript, you can read and write Kotlin on the very first evening. The main difficulty was not the language. Documentation in AI helped the most difficult stage with studying the IntelliJ platform SDK. The documentation at Jedbrains is huge, but the learning curve is steep. To understand which class is responsible for, right-clicking on a file, you can't spend hours on forums. Here, AI

agents came to the rescue. I didn't use them to write business logic, but as a smart search engine for the API. Queries like how to show notification balloon saved a lot of time. Instead of a digging through docs, I got a code example, and then I figured it out myself. Implementation. From templates to smart assistant. During development, I identified key tasks that would solve the team's biggest pains. The main goal was for the tool to feel native part of the I'd, and not some alien script. I won't go deep into specific APIs. What matters is what the IDE allows you to do. One, smart generation in the IntelliJ world, any action is an action. To add an item to the right-click menu, you just need to extend the class. But I didn't want to clutter the menu. Why do I need a...

Create component button if I clicked on a folder with business logic or translations. Here, the flexibility of plugins shines. The action class has in method, which is called every time before showing the menu. I added simple logic. Am I in the folder? Does the file not exist here yet? If yes, show the menu item. If not, hide it. The developer sees only the tools that are relevant right here and right now.

The generation itself is also smarter. Standard templates can't go outside the current folder, but our architecture assumes splits code by modules and often uses injection of platform implementations of business logic. So, I implemented a smart action. The developer enters the entity name once, and the plugin, creates an interface file in with boilerplate for injection, calculates paths to and modules, creates corresponding implementation files in those folders, corrects file and class names, Kabob case for files, Pascal case for, classes. Important nuance. I didn't hardcode the templates inside Kotlin classes. This would make the plug-in a black box. Instead, the plugin registers layouts in the standard-eyed settings. This gives us flexibility. Any team member can go into the settings, correct the code style in the template, and the plug-in will immediately pick up the changes. Two. I-18 North Navigation the second problem is,

dead, text. We use a custom hook and a component. Toth-eyed. This is is a meaningless string to bring them to life, I used. This API lets you tell the I'd. Look, if you see a string inside this hook, treat it as a link to a JSON file. Now, holding, I can click on the translation key and jump to the right localization file. No more manual searching. Once I started, I couldn't stop. As soon as the entry barrier was gone and the basic framework was ready, I got carried away. It turned out that having access to the ast, abstract syntax tree, of the code lets you do wonders. Auto mocks. The plugin generates mock data for tests based on the interface. Wiring in tests. When creating a test file, the plugin finds the necessary mocks and adds

imports automatically. Rappers, hawks, an action that wraps the selected component in an analytics hawk and passes the required props. All these are routine actions, each of which saves dozens of seconds and helps keep focus on the main task. Distribution greater than delivering the tool to team was simple. No sending. JAR files in Slack. Greater than the plugin is published on the JetBrains marketplace. For a new developer, greater than onboarding now looks like this. Install WebStorm, download our plugin, and greater than you're ready to go. Summary. Developer experience is in your hands. Was it worth it? Spending time studying infrastructure, setting up the environment, and coding in a foreign language to save a couple of minutes a day,

Absolutely. If you count pure time, the savings might not look huge, maybe an hour or two a month. But the real value is not in minutes, but in flow. When the tool works predictably and fast, the micro annoyances that build up during the day disappear. I stop thinking about which folder to put the file in or what to name it. I press a button and the eyed does exactly what is needed. This experience taught me two things. One, there are no boundaries, the division into front end and back end, or tooling often exists only in our heads. If you understand algorithms and know how to Google or ask AI, you can build tools for any platform. Kotlin turned out to be friendly, and the Intel EJ platform is powerful. 2. The I'd is a constructor. We are used to putting up with inconveniences, waiting for the vendor to release an update. But Webstorm, like VS code, is a platform. If you don't like how your hammer works, you can rebuild it. Three, if you work on a large project, and feel like you are drowning in routine, don't be afraid to spend time building your own plugin. It's an investment that pays off every single day when you come to work and just write code,

instead of fighting with the file system. Written by Alexei Kovergin, Software Engineer at Social Discovery Group, ready to shape the future of social discovery? Explore your dream career at SDG join a team that's redefining innovation. Your next big opportunity is just a click away. Right finger find your next career opportune at SDG. Thank you for listening to this Hackernoon story, read by artificial intelligence. Visit hackernoon.com to read, write, learn and publish.