Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

publish on npm?

See original GitHub issue

for folks wanting to run this locally between worktrees, not needing docker or needing to clone + compile would be a big help.

just a lil npx turborepo-remote-cache or something would be great 😄 ❤️

Issue Analytics

State:
Created a year ago
Reactions:1
Comments:9

Top GitHub Comments

1reaction

tehKapacommented, May 17, 2022

I like the idea, and it is worth trying. @tehKapa, what do you think? This could be one of the easiest ways to deploy “serverless”.

it could be a very good idea. it would become a “remoteless”

1reaction

NullVoxPopulicommented, May 16, 2022

Why do you want to run more than one instance of remote-cache?

Because my team has access to S3 management, but we can’t spin up new servers (this is a hard requirement we can’t get around right now). Additionally, even in a solo-server environment, I would not want to build from source. Releasing is a good way to communicate bugfixes, features, breaking changes, etc (SemVer, etc)

The whole point of this project is to have a shared caching server between several developers.

For my team, the plan is to (atm):

(hopefully) install turborepo-remote-cache (provided you release it on npm ❤️)
use our existing wrapper scripts to manage the start/stop/restart of the cache server per-developer (the developers would not notice this at all, because we already use wrapper scripts for everything)
the cache server per-developer will access the same s3 storage, still using a shared cache between our 160+ developers (I’ve lost track at this point)
every developer already has access to S3, so they’d use their existing keys (in their local env) for the cache server to use to communicate with S3
allow updates of turborepo-remote-cache to automatically be PR’d to us via renovate / dependabot
allow every version of turborepo-remote-cache (and its dependencies) to have security scanning (which most security scanner tools support npm packages)

I am still trying to figure out what limber does, so sorry if this is a dumb question

no dumb questions!!! but limber isn’t important – it’s just a simple monorepo and the linked PR is to demonstrate capabilities for consideration in a very very very very very large internal monorepo