Update aragon CLI to latest version #140
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "chore/update-dependencies-1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
rebased version of #139
It seems npm has some issues and a broken package-lock.json gets generated.
scripts/fix-package-lock.js(which I have taken from aragon-cli) fixes the package-lock.json.This PR contains a fixed package-lock.json, so everything should work. But if new dependencies are added we probably have to run
node scripts/fix-package-lock.jsand be generally careful with changes on the package.json and package-lock.jsonThis now also solves the apm problem. Now
open.aragonpm.ethis also available on the devchain, so we can default to that one and no longer need to configure it depending on the network.I pulled the branch and ran
npm install. Now I have a dirty package lockfile which seems to be from exactly those changes in the postinstall, but also includes changes toethereum-util.@bumi Could you please squash those 5 commits before the last one into a single commit and also make certain that you add the very last package lockfile? Thanks!
this was my very latest npm files. what is the diff of yours?
seems subsequent
npm installchanges and breaks the lock file.There was a bug in the fix-package-lock script which used the wrong path (see last commit).
Do you still have a dirty lock file after you ran the script?
After running the script manually, the tree is clean. I checked, and it is indeed missing the
postinstallproperty inpackage.json.should we run it as
postinstall? I am scared of automatic postinstalls and afik it will also run when used as dependency.It seems like that's not the case, because otherwise the
aragon-clipostinstall script would fix our lockfile, no? If we don't run it automatically, then everybody using this repo always has this problem.no, the aragon-cli script would look for a different file: https://github.com/aragon/aragon-cli/blob/master/packages/aragon-cli/scripts/fix-lockfile#L23
also only people who would want to make changes to the package-lock.json (change dependencies) would need to run that script. Even though package-lock gets dirty this branch here works (also on travis)
I didn't change anything about the packages and still had a dirty tree after the npm install. If nothing changed it should be clean after running install. It changing to something that is invalid/breaking is bad for developer UX and would inevitably result in someone committing the wrong lockfile from time to time as well.
It's possible to know if the
postinstallis run for a dependency or not. From what I read you can essentially just check if the current dir looks like your own package or not...I just tried using this branch as a dependency in
kredits-weband the package from the lockfile fix doesn't appear inkredits-web's own lockfile afternpm install. So I think it shouldn't be an issue.Edit: stupid us. Of course it's not an issue, because
aragon-cliis merely adevDependency. It's not installed outside of this repo.aragon-cli has nothing to do with this anymore - I was wrong about aragon-cli messing something up.
I guess the only question that remains is if we want to run such a hack on postinstall (which means it is run everytime kredits-contracts is installed as a dependency and not only when someone runs npm install within this repository.
It for sure is a bad developer experience if a simple install gives you a dirty lock file. Though it seems that is some npm issue... I would like to understand that and actually fix the root cause instead of running some code that fixes this symptom.
So my hope would be that this is something very temporary. (needing such a script is like wtf.)
Because I somehow dislike postinstall magic generally and because it would run everytime this is installed as dependency I'd only add a bold note in the readme.
But I am also ok with adding it as postinstall if you want.
Generally I hope we get rid of that soon™.
aragon-cli has nothing to do with this anymore - I was wrong about aragon-cli messing something up.
I guess the only question that remains is if we want to run such a hack on postinstall (which means it is run everytime kredits-contracts is installed as a dependency and not only when someone runs npm install within this repository.
It for sure is a bad developer experience if a simple install gives you a dirty lock file. Though it seems that is some npm issue... I would like to understand that and actually fix the root cause instead of running some code that fixes this symptom.
So my hope would be that this is something very temporary. (needing such a script is like wtf.)
Because I somehow dislike postinstall magic generally and because it would run everytime this is installed as dependency I'd only add a bold note in the readme.
But I am also ok with adding it as postinstall if you want.
Generally I hope we get rid of that soon™.
as far as I understand it, npm install produces a broken lock file.
why? no idea, and also not how to fix it.
a readme entry + a script that fixes it is imo enough until the root cause is fixed.
but you did not really answer my question about the postinstall script. you vote for the postinstall?
On Mon, Jun 17, 2019 at 17:07, Sebastian Kippe notifications@github.com wrote:
Definitely! Hence my suggestion to ask the aragon-cli devs about it, because it looks to me like they also introduced it as a temporary solution.
Yes, I vote for postinstall, because we have no idea when the root cause will be fixed, but we have plenty of people who should be able to run postinstall without having a broken lockfile as dirty tree after every install.
I added a
postinstallscript which runs the fix and ignores any kind of errors (for any cases it may be run in, that could cause it to break).However, it isn't actually run after the install for me!? My output looks like this:
And then the lockfile is dirty again. When I then run
npm run postinstallmanually afterwards, the lockfile is clean again. @bumi could you see what it does on your machine?yes, seems the package-lock is written after that script is executed? when I run
git statusin the postinstall I still have a clean master.Turns out it's a known issue since 2017: https://github.com/npm/npm/issues/18798
Solution is to use
postshrinkwrap(a remnant of the shrinkwrap command which at some point was added toinstallby default). Now it works.@bumi I think it's good to merge now. But could you squash/rebase your testing commits in this branch, please?
closing in favor of #142
Pull request closed