Tools & Plugin Development

When I first started at Alibaba, I quickly realized how massive the project was—around 2 million lines of code. Even fixing a small bug or adding a new feature felt like trying to find my way through a maze.

My initial job was to fix bugs on different pages. Switching between files to find where the code appeared on the page was very time-consuming.

During a break with a coworker, I asked how they navigated the codebase. They told me they would find a unique className on the page and then search for the matching code in the file. However, classNames often repeated, which made this method inefficient and sometimes led to mistakes.

To solve this problem, I created a tool called Vite-Code-Finder—a Vite plugin that made this process much easier. With this tool, developers can click on an element on the page, and it will take them directly to the corresponding code file.

For the design, I was inspired by the Dynamic Island on the latest iPhone. I liked the smooth transitions between different states, so I added similar transitions to make the plugin both easy and enjoyable to use.

The plugin significantly improved debugging speed, and soon everyone on the team started using it. Now, it's a standard tool, and every new developer's first task is to learn how to use Vite-Code-Finder.

Just like I said, it's a huge codebase, and the order of import statements is inconsistent from file to file. It's frustrating, but no one has attempted to fix it before because it might break certain parts of the code, and those issues would be hard to trace.

However, I created a plugin to sort the import statements automatically when people format the code and it works great, no technical debt. Here's the path I took to get there.

It all started simply. I found that VSCode had a built-in feature to automatically organize imports when saving a file:

1"editor.codeActionsOnSave": {
2  "source.organizeImports": true
3}

I thought, “Great! Problem solved.” But like many easy fixes, it didn’t take long to discover the limitations.

It couldn’t place key libraries like React at the top, and that bothered me. It wasn’t enough to just have things ordered—I wanted them ordered my way.

I began exploring other options, and the first tool I found was @trivago/prettier-plugin-sort-imports. It was an improvement, but there was still a critical issue.

1// @trivago/prettier-plugin-sort-imports no blank lines between important imports and comments
2import React from 'react';
3import { Button } from '@alibaba/ui';
4
5// ...

it wouldn’t let me insert blank lines between important imports and comments. Blank lines might seem trivial, but they add clarity, separating functionality from documentation. It wasn’t quite what I needed.

That’s when I came across @alife/prettier-plugin-sort-imports v1. It promised to fix this issue by inserting AST nodes to create those blank lines.

Perfect, right? Almost. The plugin had a minor hiccup when it came across comment blocks like it inserted unnecessary blank lines, making things messy again.

1/**
2 * @description a comment block
3 * @author lawted
4 */
5
6/* eslint-disable no-param-reassign */
7
8
9
10import React from 'react';

My breakthrough came with @IanVS/prettier-plugin-sort-imports. This tool took a smarter approach to comments and side-effect imports, keeping everything in place.

Yet, there was one last puzzle to solve: I needed stylesheets (.scss, .less, etc.) to always be at the bottom. This led me to tweak the solution further.

1import React from 'react';
2import { Tooltip } from 'antd';
3import './Abbr.scss';
4import { Icon as AliIcon } from '@ali/icon';
5
6// ...

Working with @alife/prettier-plugin-sort-imports v2 and v3, I added a custom setting to gather all style files at the end of the imports. It was like the final piece of the puzzle clicking into place. Now, my imports weren't just neat—they were logically structured, with room for readability and special handling for edge cases like side-effect imports.

After experimenting and fine-tuning, I ended up with this final configuration, which I now use across team projects:

1"importOrderParserPlugins": ["typescript", "jsx", "decorators-legacy"],
2"importOrder": [
3  "^react(.*)",
4  "^antd/(.*)",
5  "<THIRD_PARTY_MODULES>",
6  "^src/pages",
7  "^src/utils",
8  "^src/components",
9  "^src/services",
10  "^../",
11  "^./"
12],
13"bottomUnsortableImports": [".(le|c|sc|sa)ss$"]

With this in place, I don't just organize imports anymore—I structure them, making the code easier to read and maintain. It's not just about making things work—it's about making them work wonderfully.

For developers working on the Aone View platform, navigating between their code and issue tracking was creating friction. Though small, these tools represent my approach to improving productivity and crafting user-centered solutions.

It all started when our team made a change to the commit message format. Every commit now had to be linked to an issue ID from the Aone platform. The original format was simple:

1feat: add a new feature

1feat(assets): to#123456 add a new feature

Suddenly, every developer had to interrupt their coding flow to manually find the issue ID on the Aone platform, copy it, and paste it into their commit message. This not only took up valuable time but also pulled focus away from what really mattered—writing code.

What if developers could stay in their IDE, with everything they needed at their fingertips? That’s when I set out to create a solution: a VSCode extension that could automatically pull issue IDs from the Aone platform and insert them directly into the commit message. No more switching tabs, no more manual effort—just smooth, uninterrupted coding.

The extension integrated seamlessly with VSCode, allowing developers to pull issue IDs with a single command. No more manual work—just smooth coding. It saved time, improved focus, and received great feedback from the team.