Currently when doing a dshell clean or cleanall we delete the virtual project.
The possible problem with this approach is that we are also deleting the pubspec.lock file. The result is that we are essentially forcing a pub upgrade everytime a user does a clean.
We need to considered what is the desired behavour.
One of the traits of dart package management and the pubspec.lock file is that the lock keeps a projected pinned to a specific package version. This helps stability - e..g you don't just randomly upgrade to a new version of a dependency each time you compile.
It would seem wise that dshell takes the same approach.
If we go down this path we will need to add an upgrade option to dshell.
Something like:
dshell upgrade
or
dshell clean --upgrade
Should we reserve the 'upgrade' verb for doing dshell upgrades at a later date or can the install verb handle this?
This one needs a little more thought.
Currently when doing a dshell clean or cleanall we delete the virtual project.
The possible problem with this approach is that we are also deleting the pubspec.lock file. The result is that we are essentially forcing a pub upgrade everytime a user does a clean.
We need to considered what is the desired behavour. One of the traits of dart package management and the pubspec.lock file is that the lock keeps a projected pinned to a specific package version. This helps stability - e..g you don't just randomly upgrade to a new version of a dependency each time you compile.
It would seem wise that dshell takes the same approach. If we go down this path we will need to add an upgrade option to dshell. Something like:
dshell upgrade or dshell clean --upgrade
Should we reserve the 'upgrade' verb for doing dshell upgrades at a later date or can the install verb handle this?