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:
- resolve all imports in the project and save relations between files
- gather information about default import/export
- create a new identifier name for the named export
- 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.
I already developed it! π€ π€ spoiler
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:
-
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 usesresolve
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
- I introduced an environment variable,
-
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
- I introduced an environment variable,
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
- It's a very convenient way to see the
- 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 statementsimport something from '...'
-
ExportDefaultDeclaration
to find only export default statementsexport 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 likeReact.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
That's it, welcome to the comments below! π
Top comments (0)