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

Is there a way to partially cache dependencies? #321

Closed
oscard0m opened this issue Aug 22, 2021 · 4 comments
Closed

Is there a way to partially cache dependencies? #321

oscard0m opened this issue Aug 22, 2021 · 4 comments

Comments

@oscard0m
Copy link
Contributor

Context

Tried to add cache: npm to TypeScript's workflows but we become with a blocker: Is it possible to not cache some of the dependencies?:

Issue: microsoft/TypeScript#44924
Originally asked here


I would like to know if there is a way to cache most of the dependencies but to make sure some of them are not being cached with actions/setup-node or actions/cache. As far as I understand there's not an option with latest cache option .

@dmitry-shibanov
Copy link
Contributor

Hello @oscard0m. Thank you for your report. The task does not support of caching partially dependencies. Caching in setup-node use global directory from npm config get cache to save cache, that is why i think it's not available to skip some dependencies from being cached, because all dependencies are saved in this directory.

@oscard0m
Copy link
Contributor Author

Hello @oscard0m. Thank you for your report. The task does not support of caching partially dependencies. Caching in setup-node use global directory from npm config get cache to save cache, that is why i think it's not available to skip some dependencies from being cached, because all dependencies are saved in this directory.

Thanks for the quick and concise reply @dmitry-shibanov 👏🏽 .

I would like to explore what are the existing possibilities on supporting this. For instance, I was checking cacache lib (the one used by npm) but, for that, I'm not sure if I should address this under NPM's GitHub or this issue could be a good place to discuss and end up doing a spike for this.

What do you think @dmitry-shibanov

@maxim-lobanov
Copy link
Contributor

@oscard0m , unfortunately, we don't have much context with cacache tool so probably npm team will have more context.

May be some tricks with npm uninstall and removing non-cached dependencies from package-lock.json (or having two package-lock.json files) can help here. But it doesn't look like easy and good solution actually.

Another possible solution is adding the following step after at the end of your workflow (approximate code, I didn't test it but can help to understand the idea):

- run: |
    cache_path=$(npm config get cache)
    dep_path="$cache_path/dependencyname"
    rm -rf $dep_path
  shell: bash

The single concern from my side is that we would like to keep caching functionality in setup-node as simple as possible.

We don't pursue the goal to provide wide customization of caching in scope of actions/setup-node action. The purpose of this integration is covering ~90% of basic use-cases. If user needs flexible customization, we should advice them to use actions/cache directly.

@oscard0m
Copy link
Contributor Author

oscard0m commented Aug 24, 2021

Thanks for getting back to me @maxim-lobanov and thanks for your feedback and suggestion. My next steps will be:

  1. To research and maybe open an issue to npm team discussing this topic
  2. To get back to my TypeScript PR depending on the solution offered by npm
  3. Depending on the suggested solution by npm, maybe it could be interesting to extend it to actions/cache (in actions/setup-node no since the goal is to keep it simple with the basic use cases).

In the meantime, I'm proceeding to close this issue and refer to it in the steps I previously mentioned.


EDIT: I just found npm 7.21 released the feature of removing certain keys from the cache npm rm <key> so I guess we will need to wait until npm 7 becomes the default. Until then, I would say let's keep with this topic closed.

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

3 participants