publish on npm?

[NullVoxPopuli]

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 :D <3

[fox1t]

So basically just a command to run it locally with a default config?

[NullVoxPopuli]

almost!

kinda -- the main thing is that, in order to use turborepo-remote-cache today, I have to (instructions described here in this demo PR):

• clone the repo
• cd into the repo
• npm install
• npm run prebuild
• npm run build

which isn't scalable across more than a few people.

so, if we could add turborepo-remote-cache to our monorepo's root package.json, we could then "just use the pre-built tool".
With published packages, we also get security scanning (from whitesource or whatever else folks use).

[fox1t]

Sorry for asking more questions. I want to understand better the use case.
Why do you want to run more than one instance of remote-cache? If you need a local cache, turborepo supports it without a remote caching server. The whole point of this project is to have a shared caching server between several developers. (I am still trying to figure out what limber does, so sorry if this is a dumb question).

[NullVoxPopuli]

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 <3)
• 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

[fox1t]

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".

[matteovivona]

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"

[fox1t]

@NullVoxPopuli you can now run the command you proposed :)
Let us know if you find any issues.

[fox1t]

#24

[NullVoxPopuli]

thank you!!

I've updated my demo here: NullVoxPopuli/limber#475