Open mddifilippo89 opened 2 months ago
Yes, we know and we can't release the hgrid samples because of this currently. We are most likely hitting some limits to what is possible using react-app-rewired or create-react-app. With a lot of RAM and some pampering we can build it locally so we'll probably deploy manually. We will work on completely transferring the samples browser to vite as a long-term solution.
@turbobobbytraykov
Yes, we know and we can't release the hgrid samples because of this currently. We are most likely hitting some limits to what is possible using react-app-rewired or create-react-app. With a lot of RAM and some pampering we can build it locally so we'll probably deploy manually. We will work on completely transferring the samples browser to vite as a long-term solution.
yeah, we've been meaning to move it to vite anyhow. We would just need to update the generation templates, and the code that glues the samples into the main browser possibly.
Actually preliminary results trying vite also show memory issues. We are planning on separating the samples browser in a few different application much like the angular one works. We also don't plan on having separate samples as it just complicates things but have just one (or more) main browsers with samples being their direct children. We'll figure something out for codesandbox to work in this setup much like we did for angular.
hey @ChronosSF can we talk about this? We can't do that by hand. The samples are already individual. If we want to have several smaller SBs then what we need to do is alter the code that automatically glues the smaller samples into a larger SB..
Also teh main issue is probably excel, and a simple solution is probably just to make sure that the excel samples wind up in a different browser.
I HATE the way we did this in angular and extremely disagree that is a good strategy.
note, we also need to make sure that webpack is using the right entry point for the modules, it could be that it using the "flat" modules and tree shaking down might be using a lot more memory than if the entry points used by the bundler are the separated entry points.
@ChronosSF @dkamburov
https://infragistics.visualstudio.com/NetAdvantage/_build/results?buildId=146832&view=logs&j=d3d782b6-b531-590c-3f8c-1d057b14221a&t=20fc2f5c-b8f0-5188-1a76-c13924e7d32a&l=228