A 49-Component Import Refactor That Took Minutes Instead of an Afternoon

Hello everyone, I'm Frontend Dream Factory, a developer who has been working in the frontend and uni-app ecosystem for many years.

Currently, I'm mainly developing and upgrading a uni-app open-source component library:

• uView Pro provides 80+ high-quality components, multi-theme switching, dark mode, and multi-language internationalization. It's a relatively active component library project in the uni-app community.

In my spare time, I maintain components, fix bugs, write documentation, and occasionally use AI tools to boost my efficiency. Today, I'm sharing a real problem I solved with TRAE Work a couple of days ago.

An Overlooked Pitfall

The uView Pro open-source component library covers common scenarios like forms, navigation, and feedback. Many people use it, but there's an issue users keep asking about: it currently doesn't support single-component imports.

What does that mean? Normally, to use uView Pro, you need to configure easycom auto-import in pages.json:

"easycom": {
    "autoscan": true,
    "custom": {
        "^u-(.*)": "uview-pro/components/u-$1/u-$1.vue"
    }
}

After configuration, you can use <u-icon> or <u-button> directly in templates without importing or registering them. Sounds convenient.

But the problem is, some projects don't want to use easycom. For example, if you only want to use the u-modal component, logically you should just be able to import UModal from 'uview-pro/components/u-modal/u-modal.vue', right?

Wrong.

Because u-modal internally uses u-popup and u-loading, but its code doesn't import these two components at all. Across the entire component library's 99 files, not a single one has an explicit import declaration; they all rely on easycom to handle it.

If you take u-modal out and use it alone, it will likely throw an error — u-popup isn't registered, u-loading isn't registered.

This pitfall has existed from the very beginning, but because most people use easycom, it never surfaced until users wanted to import individual components, which simply didn't work.

There's an even more subtle scenario. Sometimes your project has multiple component libraries, and you already have a set of components with the u- prefix. To differentiate or avoid conflicts, you might want to change uView Pro's component prefix, for example to upro-:

"easycom": {
    "autoscan": true,
    "custom": {
        "^upro-(.*)": "uview-pro/components/u-$1/u-$1.vue"
    }
}

This way, writing <upro-icon> on your page works fine; easycom can find the file. But the problem lies inside the components — u-popup internally writes <u-mask>, not <upro-mask>. easycom maps the upro- prefix to the correct file path, but the tag names in the component templates don't change accordingly, so the u-mask tag is unrecognized, causing a component error directly.

Whether you don't want to use easycom or want to change the prefix to reuse components, the root cause is the same: components don't explicitly declare their dependencies internally, so they can't run without easycom's fixed prefix rules.

49 Components, 82 Import Statements

To fix this problem, the logic is simple: whichever component uses another component in its template needs a corresponding import added in <script setup>.

For example, if u-alert-tips uses u-icon, add a line:

import uIcon from '../u-icon/u-icon.vue';

Sounds easy, but in practice, you'd need to check 99 components one by one, examine their templates, find out which other components are referenced internally, and generate the corresponding import statements.

I roughly estimated that doing this manually would take most of a day — opening files, reading templates, finding used components, writing imports, checking spelling, confirming paths. At least 3-5 minutes per component, so 49 components would be 3-4 hours. And this kind of repetitive work is very error-prone; missing one, adding an extra one, or misspelling a variable name are common mistakes.

So, simple business logic is where AI coding shines. If you do this kind of thing yourself, you're basically looking down on AI... It can basically get it right in one go without needing a second conversation.

Letting TRAE Work Handle It

I opened TRAE Work and entered the requirement:

Check all components under uView-Pro/src/uni_modules/uview-pro/components. If a component uses other components internally, import declarations need to be added.

I didn't let TRAE Work directly modify the code; instead, I first entered Plan mode. It did several things:

Scanned the component directory, listed 99 components, and read the contents of each .vue file one by one.

Detected dependency relationships, using regex to match <u-xxx tags in each component's template, finding that 49 components had internal dependencies. It even listed the complete dependency map — u-modal depends on u-loading and u-popup, u-city-select depends on 5 components, and u-popup itself depends on u-icon and u-mask.

Discovered edge cases, such as u-steps having <u-icon> and <u-line> in its template, but they were wrapped in HTML comments (old commented-out code) and shouldn't count. u-calendar and u-upload had nested <template> tags, and using non-greedy regex extraction would cause content truncation, requiring a different extraction method.

Formulated a plan, writing a Node.js script to automate the task, supporting dry-run preview and idempotent execution.

The plan was written into a plan file. I reviewed it; the dependency mapping was correct, and all edge cases were considered. I confirmed and approved it.

Then TRAE Work started executing:

1. First ran in --dry-run mode, outputting the dependency relationships and import statements to be inserted for 49 components. I confirmed they were correct.
2. Executed formally, all 49 files were modified, inserting a total of 82 import statements.
3. Ran again to verify idempotency — the second execution showed "Modified 0, Already existing 49", with no duplicate additions.
4. Finally ran npm run type-check, zero new type errors (the existing 17 errors were all in demo pages, unrelated to this change).

The entire process, from scanning to verification, took a few minutes.

A Few Details Worth Mentioning

Regex lookahead assertion. The component names u-step and u-steps have a prefix relationship. Directly matching <u-step would also match u-steps. The script used a (?=[\s/>]) lookahead assertion to ensure it matched the complete tag name followed by a space, >, or /, preventing false matches.

Template extraction method. Initially, <template>([\s\S]*?)</template> was used for extraction, but u-upload had over a dozen nested <template v-if> tags. Non-greedy matching truncated at the first </template>, causing a loss of many dependencies. It was later changed to "take all content before <script", which solved the problem.

Components in comments don't count. u-steps had old rendering logic commented out, which contained <u-icon> and <u-line>. The script removed HTML comments before matching, so these two were not mistakenly added as imports. Similarly, u-select had a <u-icon> in a comment that was correctly excluded.

Import insertion position. Each component's <script setup> already had some imports (from Vue, internal to the project). The newly added component imports were placed at the end of the existing import block to maintain code style consistency.

Manual vs. Automatic

If I had done this manually, I'd probably have spent an entire afternoon. Open 49 components one by one, read templates, find dependencies, write imports, check for omissions. Then run verification myself, and if any were wrong, go back and check again.

TRAE Work finished it in a few minutes, and it was more reliable than a human — it wouldn't misspell variable names, wouldn't miss components inside nested templates, and wouldn't count tags inside comments. The script also supports repeated execution; just run it again when new components are added in the future.

What struck me is this: TRAE Work isn't a tool at the granularity of "help me write a piece of code." You give it a clear engineering task, and it analyzes the current situation, discovers edge cases, formulates a plan, executes, and verifies. What you need to do is review the plan and confirm the direction, not watch it write code line by line.

That plan file is what I find most valuable — thinking through what to change, how to change it, and what pitfalls exist before starting is probably much more reliable than diving in headfirst. This workflow applies to any batch refactoring task: scan first, then analyze, produce a plan, confirm, and execute.

For problems like this, manual work is truly no longer needed. If you do it all yourself, what's AI for? And Trae Work handles it much better than you can.

Let yourself off the hook, hand it over to AI.