Split chunks into individual dirs

[sidharthv96]

📑 Summary

This will help downstream users if they want to include only a subset of the dist in their bundles.

The files below do not have chunks, hence the missing folders.

Resolves #4203

[codecov]

Codecov Report

Merging #4733 (13852b7) into sidv/esbuildV11 (8f44de6) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@               Coverage Diff                @@
##           sidv/esbuildV11    #4733   +/-   ##
================================================
  Coverage            46.09%   46.09%           
================================================
  Files                   53       53           
  Lines                 6736     6736           
  Branches                32       32           
================================================
  Hits                  3105     3105           
  Misses                3630     3630           
  Partials                 1        1           

Flag	Coverage Δ
unit	46.09% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[sidharthv96]

@aloisklink, what's you opinion on shipping all the .map files?
It will significantly reduce the npm install bundle size. Which all .map files are actually needed? (Does core need maps?)

They are the main factor to this size increase.
Current

v11.0.0-alpha.3

The dist folder is only 14.7 MB without the map files.

---

I just realised that the source maps were not linked from our files, so they were essentially not being used by the browser.
The amount of bug reports we get with logs are miniscule, and even those didn't have sourcemap support till now.

So, I think we can remove the maps entirely in v11, and add it back if there are any complaints?

200TB saved per week (uncompressed).

Without maps

package size: 4.4 MB
unpacked size: 14.7 MB
total files: 306

With maps

package size: 16.0 MB
unpacked size: 65.6 MB
total files: 420

Savings/week with 4,55,756 downloads.

Bandwidth: ~50TB
Disk write: ~220TB

[aloisklink]

@aloisklink, what's you opinion on shipping all the .map files?
It will significantly reduce the npm install bundle size. Which all .map files are actually needed? (Does core need maps?)

I'd love to have map files, but I think they're currently broken. All of the map files point to the ./src/ dir, but we don't upload the ./src/ dir to NPM, so I don't think they do anything currently.

This is a shame, map files would have helped a lot when I've previously been trying to debug bugs in Mermaid.

My feeling is that:

• map files are nice to have, but are probably only required by in the .core.esm.mjs build, since that's the build that NPM/JavaScript devs are most likely to use.
• map files need the src/ dir, but we can't really easily add that to the NPM dir, because the src/docs folder has a lot of junk in it (e.g. Vitepress node_modules folder??)

So maybe remove the map files for now, and once move the docs out of the packages/mermaid folder (see #4382), we can consider adding the map files for core.esm.mjs back in?

---

As another file saving, we could make both mermaid.js and mermaid.min.js the same file (same with mermaid.esm.mjs and mermaid.core.esm.mjs). I know we need to keep both files for backwards compatibility, but I feel like there's no reason why both files can't be the exact same minimized version.

[sidharthv96]

As another file saving, we could make both mermaid.js and mermaid.min.js the same file (same with mermaid.esm.mjs and mermaid.core.esm.mjs). I know we need to keep both files for backwards compatibility, but I feel like there's no reason why both files can't be the exact same minimized version.

I just realised both are actually the same. But shouldn't mermaid.js be the non minified version?
We are missing a flag in the build options. Setting that fixes the issue.

[aloisklink]

But shouldn't mermaid.js be the non minified version?

It currently should be the non-minified version, yes. But why do we even need to publish a non-minified version? IMO, the only benefit is the non-minified version is easier to debug.

Although, that's probably something to change in a future PR! I'll say keep the old behavior (mermaid.js and mermaid.esm.mjs are non-minified) now. We can then make another PR in the future (maybe even for a Mermaid v11.1 release), that will minify them to save space. That PR will probably need to get a 👍 from more reviewers, since although I think it should be a non-breaking change, touching the entry-points is always high risk.