Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Make runtime footprint smaller #44

rigor789 started this conversation in 1. Ideas & Discussions
Sep 15, 2022 · 4 comments · 4 replies
Discussion options

Right now if you are working with multiple projects, all of them have a pretty large node_modules folder, partially due to the size of the ios and android runtimes, and a lot of storage is wasted and it adds up quickly.

Proposal: make @nativescript/ios and @nativescript/android lightweight "placeholders" that indicate to the CLI (or a postinstall script / script invoked by the CLI) where/how to fetch the runtime files and reuse them if they have already been downloaded to a global cache directory.

  • make npm packages lightweight
  • cache runtime files (per version) in a global cache folder
  • perform checksums to avoid corrupted downloads/caches
  • reuse cached runtime if present
  • keep a "last-used" metadata file in cache directory and auto-cleanup when a specific version has not been used for X amount of time (prevents excessive cache buildup over time)
  • allow cleaning the cache easily - perhaps ns clean --full or something similar

The actual runtime files would need to be hosted perhaps as GitHub release assets, this definitely complicates the publish pipeline, however we are (I believe) getting close to the npm package size limit, so sooner or later we might need to do this anyways.

/cc @edusperoni @triniwiz @NathanWalker

You must be logged in to vote

Replies: 4 comments · 4 replies

Comment options

I really like the idea. Implementing that we could also detect runtime version change and force a clean of platforms in this case. Could prevent a lot of false positive bug reports.

You must be logged in to vote
0 replies
Comment options

I've mentioned this before, but prisma is a good example of this.

https://www.npmjs.com/package/@prisma/engines is responsible for downloading and setting up the versions. They use https://binaries.prisma.sh/

They also allow you to specify specific files for it to use, so if you want to test some other binary version you just need to specify some environment variables

You must be logged in to vote
2 replies
@rigor789
Comment options

rigor789 Oct 22, 2022
Maintainer Author

The only thing to consider is hosting costs - that's where GitHub release artifacts are nice - and pretty sure they can be automated too!

@farfromrefug
Comment options

@rigor789 they definitely can. I already build android v8 through github action and adding them to a release is really easy

Comment options

I think a simpler solution is to publish ios runtime on Pods & android runtime on maven. This makes npm installs small & gradle/cocoapods hande all the painful stuff for us automatically when you build the native app.

You must be logged in to vote
0 replies
Comment options

@ammarahm-ed I dont think pods can actually.host any file. Pod repo only holds manifests. The file needs to be hosted somewhere else.
Ans maven might have a size limit.

You must be logged in to vote
2 replies
@rigor789
Comment options

rigor789 Mar 1, 2023
Maintainer Author

We are experimenting with hosting the large files on GitHub Releases/Artifacts and linking to those from a Podspec (for iOS).

If that proves to work nicely, we can do something similar for Android (tbd)

/cc @ammarahm-ed

@ammarahm-ed
Comment options

Awesome. I think it will work out nicely. I have seen many projects use it and they work great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.