Skip to content

Conversation

@jonasfj
Copy link

@jonasfj jonasfj commented Feb 14, 2025

Correct me, if I'm wrong here, but it looks like this package modifies files in PUB_CACHE, is that correct?


Please advise users not to use this package.

Please consider flagging this package as discontinued on pub.dev.

Modifying PUB_CACHE is bad, users who do this, might not realize that they've poisoned their PUB_CACHE. They might have been using patch_package on a toy project, and suddenly they'll be using their patches in other unrelated projects because they are stored in PUB_CACHE.

They might get weird unexplained behavior months or years later in totally unrelated projects, because files in their PUB_CACHE have been modified in arbitrary ways. They'll report bugs that maintainers can't reproduce! They won't be able to reproduce their behavior in CI or on other machines. They might think their their personal computer has a very weird problem with Dart or Flutter, one that nobody else has. If you've forgotten that you've modified your PUB_CACHE, it can be really hard to figure out why something is broken.

To be fair: I've certainly used go-to-definition and inserted print statements during debugging, and I've also experienced these unexplained prints showing up in logs of another projects weeks later with no explanation -- So I'm by no means perfect 🤣🤣🤣

But I'd still advice against this, and certainly warn people of the dangers!

You can also change how it works!

You could copy the package to be modified into .dart_tool/patched-packages/<package> and then either:

  • Create a pubspec_overrides.yaml that specifies a dependencies_overrides with a path-dependency on the package in .dart_tool/patched-packages/<package>.
  • Use dependency_overrides in pubspec.yaml to create a path-dependency pointing at .dart_tool/patched-packages/<package>.
  • Modify .dart_tool/package_config.json to point to .dart_tool/patched-packages/<package>
    • WARNING This also won't work will, and will probably break various tooling, but at-least you won't be breaking every project / tool on the users computer going forward!

Or do something like package:vendor, though it's certainly not a perfect solution.

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

Successfully merging this pull request may close these issues.

1 participant