Include paket.lock file?

[isaacabraham]

Given that we're now including a yarn.lock file, shouldn't we do the same with paket.lock? Not only will this increase the speed for the first build (important IMHO), but will also allow us to ensure stable releases.

[Krzysztof-Cieslak]

Uhh, we don’t do that? Yeah, we definitely should, IMO

[theimowski]

It's tricky given the options of template.
Have a look e.g. at paket.dependencies - There's a lot of conditionals based on the input parameters (Server, Remoting, Fulma).
If we were to include a paket.lock, we'd have to generate one for each permutation of the available options.

What could be done is restrict the dependency versions - more stable releases, but still compromising first build speed.

[isaacabraham]

Hmmmm. This is going to get worse as well now that we're adding Azure dependencies in (AppInsights soon, and then Storage as well). The install process doesn't actually take that long, especially since install:none is set.

I suppose that the only alternative would be to not have any conditionals at all and just have a single lock file for everything - not a great solution though.

[theimowski]

Yep I think the advantage of fast first build doesn't outgrow the cost of having unused dependencies in the project. Closing for now

[theimowski]

reopening - it's getting more and more irritating, specially since stuff like AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#965 happens and one cannot have deterministic build when creating from given version of template...
@matthid suggested using groups for this, that could work but would require quite a lot of effort

[supertom44]

I just came to create a new project from the template and got caught out by the above-linked error.

Is there a quick workaround while the issue is being resolved?

Cheers.

[theimowski]

You can pin System.IdentityModel.Tokens.Jwt to a previous version, IIRC 5.2.2

[isaacabraham]

@theimowski how about a compromise here - let's either:

1. Create a paket lock for when the default options only are selected. Otherwise, it doesn't create one.

2. OR we create a massive lock file that contains everything for all packages (this potentially introduces other problems though).

I demoed creating a SAFE app from scratch the other night and had to pre-generate the lock file because it simply took too long otherwise.

[forki]

Yes lock file for default seems a good solution Isaac Abraham <notifications@github.com> schrieb am So., 24. Juni 2018, 17:36:

…

@theimowski <https://github.com/theimowski> how about a compromise here - let's either create a paket lock for when the default options only are selected. Otherwise, it doesn't create one. OR - we create a massive lock file that contains everything for all packages (this potentially introduces other problems though). I demoed creating a SAFE app from scratch the other night and had to pre-generate the lock file because it simply took too long otherwise. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#66 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgND9-nbbJnA1bNfh22P-7sUSzFSxyks5t_7HkgaJpZM4TmVDU> .

[isaacabraham]

OK - let's look to do that after #101 goes in.

[isaacabraham]

I've just tested out with a clean safe template and included a ready-made paket.lock, it definitely helps a lot. The biggest slow downs that I saw now are (I think) compilation of the javascript side and also this "linking" process of the yarn dependencies. Is there any way that we can "precompute" that as well?