Feature request: deno clean

[nayeemrmn]

Remove the cache files corresponding to the given targets.

• deno clean src/mod.ts ≈ rm -f $DENO_DIR/gen/file$PWD/src/mod.ts.{js,map,meta}
• deno clean dir1 dir2 ≈ rm -rf $DENO_DIR/gen/file$PWD/{dir1,dir2}
• deno clean https://deno.land ≈ rm -rf $DENO_DIR/{deps,gen}/https/deno.land
• deno clean --remote ≈ rm -rf $DENO_DIR/{deps,gen}/!(file)
• deno clean --history ≈ rm -f $DENO_DIR/deno_history.txt
• deno clean --web-storage=<URLs> ≈ rm -rf $DENO_DIR/web_storage/{<URLs>} refs Implement localStorage #1657, discussion: --location=<URL> option #4981
• deno clean --all ≈ rm -rf $DENO_DIR

Due to the current cache structure, cleaning for remote modules can only be done per-domain or coarser.

[kevinkassimo]

See #1687

[cawa-93]

I see an easy way to delete an outdated cache. This can be useful until a better solution will found.

First of all, I assume that the entire cache of your project is located in a subfolder and not globally.

DENO_DIR=/path/to/project/dir/.deno

Then, you need:

• Generate a list of fresh dependencies.
• Delete all cache
• Restore only those dependencies that were on the list.

Make it easy with the commands:

deno cache --lock=lock.json --lock-write src/entry.ts
rm -rf $DENO_DIR
deno cache -r --lock=lock.json src/entry.ts

[lucacasonato]

Partial duplicate of #2297?

[nayeemrmn]

Yeah I found that at some point after opening this. I'd like to keep it though since it gives a somewhat detailed specification...

[jsejcksn]

Copying an idea from #2297 since that issue was closed in favor of this one:

---

I think it's logical for this functionality to be an additional argument to deno cache, using something like --delete or --invalidate, and it would change the behavior of the command to delete the cached module and its dependencies.

An example:

Caching:

% deno cache --reload http://localhost:8080/local-modules/asdf@v0.1.3/mod.ts 
Download http://localhost:8080/local-modules/asdf@v0.1.3/mod.ts
Download http://localhost:8080/local-modules/asdf@v0.1.3/deps.ts
Download https://deno.land/x/semver@v1.0.0/mod.ts
Download https://deno.land/std@0.58.0/testing/asserts.ts
Download http://localhost:8080/local-modules/process-io@v0.1.2/mod.ts
Download https://deno.land/std@0.58.0/fmt/colors.ts
Download https://deno.land/std@0.58.0/testing/diff.ts
Compile http://localhost:8080/local-modules/asdf@v0.1.3/mod.ts

Deleting:

% deno cache --delete http://localhost:8080/local-modules/asdf@v0.1.3/mod.ts 
Delete http://localhost:8080/local-modules/asdf@v0.1.3/mod.ts
Delete http://localhost:8080/local-modules/asdf@v0.1.3/deps.ts
Delete https://deno.land/x/semver@v1.0.0/mod.ts
Delete https://deno.land/std@0.58.0/testing/asserts.ts
Delete http://localhost:8080/local-modules/process-io@v0.1.2/mod.ts
Delete https://deno.land/std@0.58.0/fmt/colors.ts
Delete https://deno.land/std@0.58.0/testing/diff.ts

[nayeemrmn]

I think it's logical for this functionality to be an additional argument to deno cache

With the number of clean-specific CLI flags in this proposal, that would not be logical. Also consider the number of cache-specific flags that won't matter when cleaning -- deno cache acts more like a "prepare" or "build" step i.e. cargo build vs cargo clean. The name "cache" is prompting you to suggest this but they're not similar.

it would change the behavior of the command to delete the cached module and its dependencies.

Deleting all modules that are dependencies of x is an odd concept to me, given that dependencies can be shared. I can't think of a proper use case for this that isn't met by --reload. If this feature ends up being highly requested, we can add deno clean --recursive. I'm not in favour of making this the only capability just for some cosmetic alignment with deno cache.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jsejcksn]

Not stale

[Nukiloco]

What is the current status of this?

[bartlomieju]

What is the current status of this?

As indicated by lack of comments for over a year, there's no progress and currently no intention to implement this.

[randallb]

Would this be a good first issue?

[bombillazo]

Hey, please consider adding this CLI feature; it would be great for more control and debugging with deno functions locally!

[nayeemrmn]

I'm thinking we should ship a flat deno clean which deletes $DENO_DIR for now, and visit granular flags in separate issues based on demand.

• This issue has a lot of upvotes but it doesn't tell us if users just want a deno clean to occasionally invoke (like me) or are interested in one of the granular options.
• We want to avoid designing anything that is tied to the current non-stable caching strategy. Some of the bullets I listed haven't aged well if you're familiar. And on second thought deleting deps by registry origin isn't useful.

A new list would look like this for me:

• deno clean: Delete $DENO_DIR.
• deno clean --ts: Delete TS cache whatever that may mean. Currently we cache transpilations and successful checks.
• deno clean --remote: Delete download cache for http/https modules. Could extend with =<url-prefix> later.
• deno clean --npm: Delete NPM registry cache. Could extend with =<package-name> later.
• deno clean --web-storage: Delete web storage. Could extend with =<origin-or-main-module-url> later.
• deno clean --fmt --lint --lsp --etc.: Delete whatever incremental caches are used for each respective tool. Doesn't matter if they don't exist later IMO.

Either way I want to punt these for later.

[Xe]

This just bit me in prod, my deno generated folder was somehow two gigs