Konstantin Raev
Konstantin Raev
It makes sense to be consistent in implementation and vocabulary between this RFC and #68. Maybe this one could actually piggy-back on #68 implementation?
@magicmark, we might want to discuss more how upgrade-interactive would work modifying the resolutions described in #68.
@magicmark sorry for stalling on reviewing this RFC. I have read it through once more after going through #68 and #71. It seems like your RFC covers and intends to...
We may want to split the discussion into several RFCs. Feel free to spawn your own version
In terms of complexity I would not sign up on this drastic change yet. There are many hidden drawbacks not listed in this RFC and code complexity and compatibility need...
Yep, that is what we need to do
1. I would go ahead and start a new RFC. 2. How about still using public URLs in yarn.lock but if you have a private repository in the config the...
Yes, that seems correct, thanks a lot for helping out! On 2 June 2017 at 18:29, Hutson Betts wrote: > :1. I would go ahead and start a new RFC....
great points, @victornoel!
I have some concerns. This change would save some code duplication between parent workspace' and children workspaces' package.json files. Is it a big deal, can you add real life use...