How to Update Your UI Without Screwing Everything Up

Making changes to web UI elements can be a bit of a minefield. Sure, in an ideal world, your layout would be perfectly encapsulated, and you could make layout updates safe in the knowledge that if it looks right in one place, it’ll look right everywhere. But while your code is, of course, written perfectly, it sadly has to live in a world of collapsing margins, ‘float: left’, and z-index contexts, which can ruin even the best laid (out) plans of mice and men.

Depending on your preferences, a combination of ctags, IDE tooling, and grepping can find most of the places the component you’ve changed is used, but that can be tedious, and “most” isn’t exactly the strongest of assurances. And finding which components might be affected is just the first step; you still need to figure out where to find them in the UI so that you can see what they look like. If you’re lucky, you just happen to know where to look — which is rare for all but the smallest front-end codebases or the most encyclopedic of memories. In most cases, you’ll chase the dependency tree level by level until you find something you recognize.

There has to be a better way, I hear you cry.

Well, now there is . . . for those of y’all using webpack: find-module-uses. It’s a little CLI utility to solve this exact problem. Using the profile that webpack makes available, it finds and lists the components that might be affected by your change, and tells you where to find them so you can check for yourself.

An Example of find-module-uses in Action

Recently, while updating the look of Flexport’s shipping locations page, I needed to add a map to the sidebar. Fortunately for me, a coworker had already done the hard work of creating a reusable map component. Unfortunately for me, however, they’d assumed that the map would always be a fixed size, while I needed it to expand to fill all the available space. The update to allow StaticMap.jsx, my coworker’s component, to fill the available space was straightforward, but I needed to make sure that in doing so, I hadn’t ruined the layout at the existing call-sites.

find-module-uses to the rescue!

The last use listed, LocationDetailsSidebar, was the usage I had added, but PortField, GeoBoundMultiSelectField, and NetworkStaticMap were unknown to me. However, thanks to the example paths listed below each use, they were easy enough to find.

1st use: PortField
2nd use: GeoBoundMultiSelectField
3rd use: NetworkStaticMap

Those first two look right, but NetworkStaticMap definitely doesn’t — the pin, rather than being centered, appears off to the side. This is a mistake I’d almost certainly not have noticed otherwise.

NetworkStaticMap, fixed

Much better. And now the changes are ready for a worry-free pull request!

Additional Bonus

For more fine-grained exploration of import dependencies, the package comes with an additional command: ‘show-module-dependents.’ It’s a little lighter weight than, and supports printing directly to the terminal as well as use with or the cli tool “dot.”

Printed to the terminal
Rendered with graphviz

Try It Yourself

If any of this is useful to you, you can check out the the utilities at, along with additional documentation and examples. Hopefully, it’ll help you make front-end changes with a little more confidence.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.