source-map-explorer
source-map-explorer copied to clipboard
Recursive / nested source map analysis?
I'm not sure where to start to investigating why this recursive / nested source map of the same chunk sizes is happening so it can be fixed, if necessary. Is this an artifact of how source-map-explorer visualizes the maps, or how create-react-app is building, etc.? How can it be fixed?
This is a new behavior I've not noticed before and seems messy.
Any input is appreciated.
Please provide the exact CLI command. What is result looks like in JSON format?
This is blank CRA

Thank you @nikolay-borzov. I am running yarn source-map-explorer 'build/static/js/*.js' against the project and get the weird result shown in the initial post. I have not ejected the CRA project, so it's using built-in scripts.
A moment ago, I created clean CRA project and get the same analysis as you (pretty clean).
Is the weird recursive nesting artifact normal, or abnormal for a mature project? Any advice in how to find the cause and fix it would be hugely appreciated. I don't quite know how to refer to this issue to do searches on it.
Not sure if it's relevant, but this is my tsconfig.json:
{
"compilerOptions": {
"target": "es5",
"lib": [
"dom",
"dom.iterable",
"esnext"
],
"allowJs": true,
"skipLibCheck": true,
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
"strict": true,
"forceConsistentCasingInFileNames": true,
"module": "esnext",
"moduleResolution": "node",
"resolveJsonModule": true,
"isolatedModules": true,
"noEmit": true,
"jsx": "preserve",
"outDir": ".build",
"rootDir": "./",
},
"include": [
"./src",
"./typings"
],
"exclude": [
"node_modules"
]
}
Is the weird recursive nesting artifact normal, or abnormal for a mature project?
A visualization like this looks abnormal to me.
Could post the result of yarn source-map-explorer 'build/static/js/*.js' --json?
Each visualization node is built from files key. For example
"../node_modules/react-dom/cjs/react-dom.production.min.js": {
"size": 117513
},
Turns into 5 nested nodes
@nikolay-borzov, Apologies for the slow response. I believe I found the cause of the anomaly!!
Because I develop on several systems at different locations, I use Dropbox to sync files in-real-time and then use git to manage the repo. This enables me to move freely between systems without worrying about dropping any work. HOWEVER, because Dropbox does not have a "true ignore" feature without reindexing (horridly slow), I use a symlink to ~/Downloads/project_name/node_modules. When this symlink is in place, the weird nesting happens. It seems like a perfect sync solution, but this is a newly discovered and unexpected side-effect.
STEPS TO USE A SYMLINK:
- cd YOUR_PROJECT_NAME
- mkdir -p ~/Downloads/node_modules_for_YOUR_PROJECT_NAME
- mv node_modules ~/Downloads/node_modules_for_YOUR_PROJECT_NAME
- ln -s ~/Downloads/node_modules_for_YOUR_PROJECT_NAME/node_modules
A post in the Dropbox Community discussing the issue and steps can be found: Here
QUESTIONS:
- Is the use of a symlink causing any real inefficiencies in the build, or is this just a zero-cost artifact of the build / source-map-analyzer?
- What is really happening here?
- Do you know of a way to resolve the anomaly while preserving the use of a symlink?
[edit: removed .json dump]
I think this is the same issue as #137, Collapse non-contributing directories.