Pub: Add "pub clean"

[matanlurey]

The goal being to revert to a state before pub interacted with the package, for example:

• Deleting .pub
• Deleting pubspec.lock
• Deleting .packages

I realize there is pub cache repair, but I'm not sure that does the same thing.

[zoechi]

pub cache repair re-downloads packages in ~/.pub-cache from pub.dartlang.org to repair them in case some files were accidentally modified or not downloaded or whatever could have happenened to them.

Isn't Git better suited for what you want to do?

[daftspaniel]

FWIW I had a situation this morning that pub cache repair simply would not fix. Some meta data was wrong so nothing at all was redownloaded. Had to resort to caja and shift delete.

Given it is a hidden folder and any level of user could hit the issue, exposing it as a command seems worthwhile.

[nex3]

I'm okay with this.

[chalin]

So, is the request to only clean out package local pub folders and files, or to (conditionally) also clean out the pub cache? Maybe these should be two commands (or one command with an extra option)?

[nex3]

I believe this request is only for cleaning the local package. I could also imagine pub global clean, although there's some difficulty there because we don't know which packages are still reachable from relevant projects. Regardless, I think that's outside the scope of this issue.

[aliyazdi75]

@nex3 any update since 2017?

[jonasfj]

I'm not sure we need this... It's customary to put .dart_tool/ and .packages in .gitignore.
And pubspec.lock should be under version control -- unless you're developing a package, in which case you can argue both ways.

What is the motivation/use-case for this? When is it useful to remove these files?

[aliyazdi75]

pubspec.lock should be under version control

First, I don't know why we should keep under version control?
Second, I don't know what happened to my dart packages have been cached and I had to repair them but it tooks me along time and what the author said.

[natebosch]

First, I don't know why we should keep under version control?

See https://dart.dev/guides/packages#upgrading-a-dependency

If you are developing an _application_ that isn't published to pub it is generally best to include pubspec.lock in your repository so that all authors have a consistent set of dependencies.

If you are developing a package that gets published to pub and may become a dependency of applications, it's generally best to not commit pubspec.lock because it isn't an accurate view of what dependency versions will end up mixed with the package in the real uses.

Second, I don't know what happened to my dart packages have been cached and I had to repair them but it tooks me along time and what the author said.

I think that is unrelated to this issue. This feature would not replace pub cache repair or solve the same problems in a faster way. FWIW if you delete the pub cache manually (check the .packages file for an idea of where it is) and then run a pub get it may be faster than pub cache repair since the latter will re-download _all_ package versions you've ever used, including some you may not be using anymore.

[aliyazdi75]

@natebosch
Thanks for your reply.
It was helpful and I got it.

[MartinHlavna]

What about cleaning space on drive? Getting rid of unused packages, older versions...

[PDalc]

I also vote for a "pub clean" feature. I just hit a problem where I included dart:io in an angular component (which I didn't realize was disallowed, oops!). This led to the following one-time compiler warning saying that my web/main.dart file was being skipped by the compiler:

[WARNING]build_web_compilers:entrypoint on web/main.dart: Skipping compiling my_project_name|web/main.dart with ddc because some of its transitive libraries have sdk dependencies that not supported on this platform

Unfortunately, I didn't notice this warning (perhaps because my kids were bugging me at the time ;-) ). Subsequent builds did not show this warning at all, because dart builds seem to be incremental. So I spent a few hours tracking down this issue. One of the first things I tried to do was a manual "clean", but I unfortunately didn't remove all the appropriate files/folders and therefore didn't see that warning again. A "pub clean" feature would have done a proper full clean and thus re-triggered this warning and brought it back to my attention.

Incidentally, it seems like the above warning should perhaps be an error instead, considering how serious the consequences can be.

[natebosch]

Subsequent builds did _not_ show this warning at all, because dart builds seem to be incremental. So I spent a few hours tracking down this issue. One of the first things I tried to do was a manual "clean", but I unfortunately didn't remove all the appropriate files/folders and therefore didn't see that warning again. A "pub clean" feature would have done a proper full clean and thus re-triggered this warning and brought it back to my attention.

The builds are indeed incremental. The command you are looking for does already exist, pub run build_runner clean. The "clean" you are looking for here is not from pub, but from the build system.

Incidentally, it seems like the above warning should perhaps be an error instead, considering how serious the consequences can be.

It's not an error because in projects that have things like a mix of VM only and web only tests we wouldn't want to fail the entire build because a VM specific test isn't built for the web.

[PDalc]

@natebosch Thanks for letting us know about "pub run build_runner clean" utility! I tried it out and it does work as I'd expect: it cleans up the source outputs and causes build warnings to be-reissued (that wouldn't otherwise be reissued due to dart build tools' default incremental build strategy).

However, I wanted to point out that this "clean" tool doesn't seem to remove absolutely everything that's been generated by the dart tools. In my test, it left behind the following files:

.packages
pubspec.lock
.dart_tool\package_config.json
.dart_tool\build_resolvers\sdk.sum.deps
.dart_tool\build_resolvers\sdk.sum
.dart_toolpub\bin\build_runner\build_runner.dart-2.10.0.snapshot

I am quite new to dart so I'm not sure if there are cases where the user would have modified these files and wanted to keep the modifications, _versus_ the risk that these files would have become corrupt in some manner and would benefit from being deleted/regenerated? If I delete all of the above files then run "pub get" and build my app, they do get auto-regenerated.

Thanks again for your help!