Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recursive / nested source map analysis? #155

Open
n8sabes opened this issue Jan 13, 2020 · 5 comments
Open

Recursive / nested source map analysis? #155

n8sabes opened this issue Jan 13, 2020 · 5 comments

Comments

@n8sabes
Copy link

n8sabes commented Jan 13, 2020

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.

Screen Shot 2020-01-12 at 4 50 46 PM

@nikolay-borzov
Copy link
Collaborator

nikolay-borzov commented Jan 13, 2020

Please provide the exact CLI command. What is result looks like in JSON format?
This is blank CRA
image

@n8sabes
Copy link
Author

n8sabes commented Jan 13, 2020

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"
  ]
}

@nikolay-borzov
Copy link
Collaborator

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

@n8sabes
Copy link
Author

n8sabes commented Jan 20, 2020

@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:

  1. cd YOUR_PROJECT_NAME
  2. mkdir -p ~/Downloads/node_modules_for_YOUR_PROJECT_NAME
  3. mv node_modules ~/Downloads/node_modules_for_YOUR_PROJECT_NAME
  4. 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:

  1. 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?
  2. What is really happening here?
  3. Do you know of a way to resolve the anomaly while preserving the use of a symlink?

[edit: removed .json dump]

@n8sabes
Copy link
Author

n8sabes commented Jan 26, 2020

I think this is the same issue as #137, Collapse non-contributing directories.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants