Building a Codemod Tool for Rewriting Default Exports

Recently at work, we decided to migrate to the named exports/imports and add the eslint rule no-default-export.

Motivation sounded something like:

The default exports can make code harder to maintain, especially in large codebases. Imported names might be different for the same entity, affecting the code reading process and writing static analyzers, making it more difficult. Conversely, switching to named exports removes all the disadvantages of the default exports.

Of course, we have a huge code base and it is not an interesting job to manually replace ~1500 default exports and ~12000 default imports 🤪

The main difficulty was updating all linked files with the same new identifier, created for the named export.

I give you an example:

// Button/Button.tsx
const Button = () => {};
export default Button;

// Button/index.ts
export { default } from './Button.tsx';

// SomePage1.tsx
import OldButton from './component/Button';

// SomePage2.tsx
import TestButton from './component/Button';

And the target result supposed by me would look like this:

// Button/Button.tsx
export const Button = () => {};

// Button/index.ts
export { Button } from './Button.tsx';

// SomePage1.tsx
import { Button as OldButton } from './component/Button';

// SomePage2.tsx
import { Button as TestButton } from './component/Button';

Each solution I found on the internet was just a codemod to transform each file independently without knowing anything else outside that file.

I started dreaming about a parser that would:

1. resolve all imports in the project and save relations between files
2. gather information about default import/export
3. create a new identifier name for the named export
4. replace all entries across the repo 😇

So I took a new challenge to develop a codemod tool that automatically rewrites default exports/imports to named ones.

spoiler

I already developed it! 🤜 🤛

Development process

First thoughts
It happened right after my previous experiment Visualize react components tree and the first idea was to reuse the babel and webpack plugins to iterate through all modules and parse the AST, but why, if jscodeshift already has the parser, and if I found a replacement for the webpack plugin I would be able to write a bundler-agnostic tool, great 💪

Tools
Ok, I have a jscodeshift as a parser. But to find relations between all files starting from the entry point, I found the resolve package, which helps to resolve paths like native nodejs require.resolve, but it is more similar to resolving paths like bundlers, you have more control over extensions, sync/async behavior, etc.

Engineering the Two-Step Process
The initial version of my tool was like everything in one script. However, to improve flexibility and performance and also simplify the development process with debugging, I refactored the tool into two stages:

1. Data Collection: The first phase gathers all instances of default imports and exports across the codebase

   • I introduced an environment variable, IS_GATHER_INFO, to control this phase. The script uses resolve to find every usage of a default export / import
   • Another env var ENTRY contains a relative path to your code base entry point, starting from that file, all imports will be resolved and analyzed

2. Transformation: Once the data is collected, the second phase rewrites the default exports into named exports. Using jscodeshift, I transformed the source code in parallel and easily.

   • I introduced an environment variable, IS_TRANSFORM, to control this phase

By splitting into these two steps:

• I was able to decouple data gathering from transformation, reducing the amount of code executed and spent time during development and debugging
  • It's a very convenient way to see the gatherInfo function's result, analyze it, rerun your code
  • Test transformations without repeatedly running the entire pipeline with the gathering data
• Collecting the data dump is helpful if you need to run this tool for different entry points but reuse the collected data

As cases began to accumulate (like dynamic imports, re-exported defaults, different exported entities: variables, functions, and classes, and already used names of variable issues) that time I spent additional time setting up test cases. In around 30 minutes I had a solid testing setup, allowing me to shift to test-driven development (TDD). Trust me, it's worth spending time on TDD for such tools, which have an enormous number of cases. The further you go the more value you feel from your test cases. I would say that after covering half of the cases if you have no tests, it becomes a nightmare to run and debug on a huge project because each time you need to add some changes, it might break a lot of other cases.

AST:
I used the following types of AST nodes:

• ImportDefaultSpecifier to find only import default statements
  • import something from '...'
• ExportDefaultDeclaration to find only export default statements
  • export default something;
• ExportNamedDeclaration to find import default and export default statements
  • export { something as default } from '...' - default export
  • export { default as something } from '...' - default import
  • export { default } from '...' - default import and default export simultaneously
• ImportExpression to find dynamic import and mark that file as needed to preserve the default export. Some tools like React.lazy work with default export only.
  • import('...')
• Also, I saved info about proxy files, it is files that import default something and export that something as default
  • Used it to find the new name of the named export in any file: file a -> file b -> file c

Technical Considerations and Known Limitations
Though the tool is functional, there are some edge cases it doesn't yet handle:

namespace.default usage
the following code won't be transformed yet:

import * as allConst from './const';
console.log(allConst.default);

Conflicts in proxy files
source:

export { Modals as default } from './Modals';
export { Modals } from './Modals';

result:

export { Modals } from './Modals';
export { Modals } from './Modals';

Messed exports like
source:

export class GhostDataProvider {}
export default hoc()(GhostDataProvider);

will result in broken logic, because now it has two same exports with different implementation:

export class GhostDataProvider {}
const GhostDataProviderAlias = hoc()(GhostDataProvider);
export { GhostDataProviderAlias as GhostDataProvider };

And imports for the previous entity should be fixed manually too
source:

// was used to get the class without HOC
import { GhostDataProvider } from '.'
...
// was used to get the class with HOC
import GhostDataProvider from '.'

result:

// now you should manually resolve it to class without HOC somehow
import { GhostDataProvider } from '.'
...
// this will get the class with the HOC
import { GhostDataProvider } from '.'

Despite these limitations, I manually fixed the rest of the errors in 15-20 minutes and successfully spun up our real project. The rewrite-default-exports.

Links

• jscodeshift
• astexplorer

That's it, welcome to the comments below! 👍