Add missing YARN lock file.

[isaacabraham]

Without the lockfile and the current configuration in the FAKE script of frozen-lockfile, Yarn will always go back to NPM to construct the lock file, both on the initial creation of a project from the template and on repeated builds.

This inserts a lock file into the template to prevent this happening. Alternatively, we should remove the frozen-lockfile argument. This would force an initial build of the lock file but (AFAIK) would afterwards simply restore packages from the lock file as per Paket restore, rather than rebuilding the lock file every time.

[forki]

Alternatively, we should remove the frozen-lockfile argument.

nooo

;-)

[isaacabraham]

@forki hey, just giving alternatives here :-) That approach has its benefits - it would mean that the template would naturally pick up the latest version of dependencies (or at least transitives) after running the template. By committing the yarn lock file, it means that we'll probably need to periodically update it for distribution (and users will need to update the template on their machines), but it guarantees a stable and consistent lock.

[theimowski]

For now I think we can lock the dependencies.
For Paket I deliberately removed lock file due to various template parameters - e.g. --Server adds different deps to paket, same with --Remoting
JS packages currently have no dependency on parameters so I'm fine with having the lock file initially (that speeds up the initial build significantly)

[forki]

If the first build would create the lock then this could work as well. Tomasz Heimowski <notifications@github.com> schrieb am Mo., 23. Apr. 2018, 22:43:

…

Merged #61 <#61>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#61 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNEp1ruh3gBE86wlqXIEqBcoqQw4zks5trjz6gaJpZM4TfaU4> .

[theimowski]

Yeah but then we'd have to check in the script if that's the first run or not, so for now it seems reasonable to just lock all js deps

[isaacabraham]

@theimowski I'm not sure if you do. If you just call yarn install I don't think that it checks for newer versions etc.? Not sure though.

[forki]

yarn upgrade --latest checks for latest.

[isaacabraham]

@forki But yarn on it's own (or yarn install) doesn't?

[forki]

Install doesn't touch package.json. So it installs latest that is fitting the specifications there. If you float in the definition then it upgrades. That's why I use frozen-lockfile. Which makes it similar to paket's restore. Isaac Abraham <notifications@github.com> schrieb am Di., 24. Apr. 2018, 08:58:

…

@forki <https://github.com/forki> But yarn on it's own (or yarn install) doesn't? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#61 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNC-MiFVyH6-EQvK3pXM_7sMIrCUeks5trsz-gaJpZM4TfaU4> .

[isaacabraham]

@forki do you mean it upgrades every single time, even if there's a valid lock file? If so then yes agreed we should stick with committed lock file and freeze.

[forki]

Yes every single time. Isaac Abraham <notifications@github.com> schrieb am Di., 24. Apr. 2018, 09:04:

…

@forki <https://github.com/forki> do you mean it upgrades *every single time*, even if there's a valid lock file? If so then yes agreed we should stick with committed lock file and freeze. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#61 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNGp8XjDwdeS1CjWpAx6xoT7R_-O7ks5trs5rgaJpZM4TfaU4> .