move sourcemap to rollup

[Duncan-Brain]

Description

This is another potential fix for the memory leak. Essentially it was found on the same vite issue: vitejs/vite#2433

Sourcemap: false also works but we want to keep it for debugging.

Sourcemap would need to be verified functional.

PR links: Fix#1 - #2495, Fix#2 - #2496, Fix#3 - #2497

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Passes test case
• UI components visually reviewed on desktop view
• UI components visually reviewed on mobile view
• Other (please explain)

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The precommit and linting ran successfully
• I have added or updated language tags for text that's part of the UI
• I have added "MISSING" for all new language tags to languages I don't speak
• I have added the GNU General Public License to all new files

[Duncan-Brain]

Just a note this may affect functionality --- so side effects would need to be assessed https://rollupjs.org/configuration-options/#output-manualchunks

[Duncan-Brain]

scratch that manual chunking wasnt necessary locally

[kathyavini]

I think you can close this. Your other PR worked great 🙂

[Duncan-Brain]

@kathyavini

I was going to maybe try figuring out how to test the sourcemap sometime this week. I think this is the preferable option if it works isn't it?

[kathyavini]

Oh, I was thinking that the preferable option is to NOT mess with the source maps if we can help it!

[iperdomo]

@Duncan-Brain can you resolve the conflict (packages/webapp/package.json) in your branch? Thanks

[iperdomo]

The change seems to work. Let's resolve the conflict with integration.

I was able to run a Docker build with 256m of memory associated.

docker build --memory 256m --progress=plain --no-cache --tag litefarm/webapp --file packages/webapp/prod.Dockerfile packages/

Attached the build log:
docker-build.log

[Duncan-Brain]

@iperdomo

If the --memory 256m was necessary on the docker statement maybe this PR is no longer working as intended.

This was meant to be an alternative to having to specify memory allocation. It was a few months ago and the fix we implemented is working right now.

I have this "Fix" here but do not fully understand how to differentiate/evaluate between the sourcemap created by vite and the one created by rollup.

So... The merge commit is in (thus the consent text changes) but if this is not a better solution to specifying the memory we can also close it and say "this is not better". And instead if there are some targeted places we can implement the suggestion in your build log --- that also could be better :

Some chunks are larger than 500 kBs after minification. Consider:
#13 56.99 - Using dynamic import() to code-split the application
#13 56.99 - Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
#13 56.99 - Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.

[iperdomo]

@Duncan-Brain no, the --memory 256m was an intentional flag to limit the amount of memory allowed for the build (from 32GB available ram). We can try with lower number.

[iperdomo]

I was able to run the build limiting the docker build process to 32m

systemd-run --quiet --user --scope -p MemoryMax=32M -p MemorySwapMax=0 docker build --memory 32m --progress=plain --no-cache --tag litefarm/webapp --file packages/webapp/prod.Dockerfile packages/

[iperdomo]

👍🏾

[iperdomo]

For the record, I was not able to reproduce the problem in the integration branch, removing the NODE_OPTIONS=--max_old_space_size=3000 parameter

[Duncan-Brain]

Closing issue - fix seems to work but the necessity of it is not clear. Defer to future fix of root problem on the following Jira ticket.

Please see LF-3348