-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using non-default resolution temporarily #4242
Comments
I think we want to be able to tell a story here eventually. For now I think the recommendation will be that to test a package's resolution in isolation you should manually take it out of the workspace (by updating the pubspec.yaml to remove the This is not ideal, as it
But it is not that hard to set up. And with git it is not hard to restore back to the working state. Note with workspaces the packages inside the workspace will always resolve to each other. You don't need to bother with overrides/path dependencies, and when you take it out of the workspace it will resolve to the hosted version of the dependency. Leaving this issue open for picking it up eventually. |
Related to #4127 |
Renamed this issue, because I think that is what we really need. One way forward would be to have:
|
When using a multi-repo approach and the new workspace concept, is it possible to easily test with locally resolved packages as well as published ones? It might make sense to want to know if a package works locally while developing, but then also checking if it still works with the published versions of the dependencies, as there is no multi-package-atomic publishing.
Currently, the workaround is running a tool to comment out lines with
path:
and instead using published versions, which is very hacky and leads to less adoption of testing this in the ecosystem.The text was updated successfully, but these errors were encountered: