Lots of generated static js files after updating to 0.7.8

[oblak1]

I'm using react v18.2 with vite 5.2.12 and nx v19.2.1

After updating to codemirror-json-schema to 0.7.8 from 0.7.0 I get a lot of autogenerated javascript files when building the project, attaching images before/after below. It generates a file for every language/platform such as wasm,angular,cpp etc.. It could have something to do with the new dep @shikijs/markdown-it - afaik other packages stayed the same.

[acao]

also noticed this @oblak1 i will look into it!

[andreyqin]

Hi @acao! Were you able to look into this? Experiencing the same issue which affects performance of my app :cry:

[miguelgrc]

Same issue here, any update @acao ? Rolling back to a previous version for the moment

[AlexErrant]

I think this code is the culprit https://github.com/jsonnext/codemirror-json-schema/blob/4fd7cc69084bdad3c8c93d9d0f0a936fa120cbae/src/utils/markdown.ts#L30-L38

We should use the "Fine-grained Bundle" documented here. Otherwise, "By default, the full bundle of shiki will be imported."

I'd PR a fix, but I'm not sure what language to import. JSON? (Do we even need to import a language at all?)

[michalkotas]

I confirm that I’m experiencing the same issue—a lot of Shiki files are generated when using version 0.7.8. I’ve reverted to version 0.7.0 as a workaround.

[AlexErrant]

So I was getting out-of-memory errors running vite build in my project:

✓ 2534 modules transformed.
rendering chunks (280)...
<--- Last few GCs --->

[7284:0x2428cb80]    71335 ms: Mark-Compact (reduce) 4064.3 (4143.1) -> 4064.0 (4143.9) MB, 3035.80 / 0.00 ms  (average mu = 0.379, current mu = 0.358) allocation failure; scavenge might not succeed
[7284:0x2428cb80]    74351 ms: Mark-Compact (reduce) 4065.1 (4144.1) -> 4064.7 (4144.6) MB, 3011.86 / 0.00 ms  (average mu = 0.207, current mu = 0.002) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0xb82c78 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
 2: 0xeefa80 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 3: 0xeefd67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 4: 0x1101905  [node]
 5: 0x1119788 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 6: 0x10ef8a1 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 7: 0x10f0a35 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 8: 0x10ce086 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
 9: 0x1529eb6 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
10: 0x7f0d53699ef6
Aborted (core dumped)
 ELIFECYCLE  Command failed with exit code 134.

I could fix with export NODE_OPTIONS=--max-old-space-size=8192, but downgrading to 0.7.4 fixed this issue, along with shaving 30 seconds and 8.5megs off my prod build. When people meme about megabytes of Javascript, this is what they're talking about 🙄

Again, I'm willing to submit a PR, but I could use guidance on what languages are actually used. Tagging @imolorhe because at this point I'm wondering about how much CO2 this feature has generated lol.

[imolorhe]

To be clear, there was no change to the bundle size of the package itself, but the dynamic chunks from shiki increased the size of the built project on disk. This issue should be fixed in the next version.