Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

module size is massive #13

Open
jpiepkow opened this issue Nov 7, 2018 · 6 comments
Open

module size is massive #13

jpiepkow opened this issue Nov 7, 2018 · 6 comments

Comments

@jpiepkow
Copy link

jpiepkow commented Nov 7, 2018

Because of ext directory the module size is massive(larger then 70mb) and makes it very hard to deploy an application to AWS lambda when it has this dependency. Is there any way to limit it to only pull the os file it needs. Not all.

@danenania
Copy link
Contributor

@jpiepkow Agreed, will be moving to post-install hooks in the near future to solve this issue. In the meantime, you could work around it by forking and removing the unneeded binaries from ext.

@samdesota
Copy link

samdesota commented Mar 15, 2020

@danenania Is this happening anytime soon?

Please also fix for other distributions. I often have to manually delete non-linux amd 64 distributions from envkey-node + envkey-python in order to use envkey with AWS lambda, or I'll go over the package limit

@danenania
Copy link
Contributor

danenania commented Mar 15, 2020

@mrapogee Fixing this issue across the board for all sdks is on the roadmap for our v2 which includes many major improvements--no release date set for this yet but we're getting there. It's doable but fairly complex to solve this in a way that won't present more cross-platform edge-case issues and allows flexibility for development vs. production, etc, so it's going to require an improved architecture for the whole build pipeline. Investigating post-install hooks left me with the impression that it will be edge-case/error prone, so have abandoned that approach--instead we will likely allow for specifying platform-specific libs for production.

In the meantime, can you fork the repo(s) and remove the unneeded binaries, then install envkey-node and envkey-python directly from your forks? I think that's the simplest solution to this currently for serverless use-cases. These libs are highly stable and not being updated frequently at this point, so you don't need to worry much about missing upstream changes--if there is something critical we'll email all users to alert them that they need to upgrade, but it's unlikely there will be many changes until v2 is released.

@pausan
Copy link

pausan commented Nov 13, 2020

I've followed your advice and uploaded an npm package from a cloned repo including only the linux64 binary, which is basically what my company needs. I made it public in case somebody finds it useful.

https://www.npmjs.com/package/gh-envkey-linux64

I'll be more than happy to deprecate the repo/npm package when the installation size of envkey npm package is smaller.

@danenania
Copy link
Contributor

Quick update on this: v2 has been released (https://github.com/envkey/envkey) and the module is a lot smaller--in the 25mb range now. Still planning to create linux specific builds along the lines of what @pausan created in v2, along with some other updates that will make it a better fit for serverless use cases.

@danenania
Copy link
Contributor

Btw @pausan I really appreciated your comment in the recent HN thread on EnvKey v2. I'd like to send you an email to get your thoughts on some things, but can't find an email for you. Could you perhaps email me: dane@envkey.com Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants