Should the lock file be included in simple template about fable-templates

[forki]

that would probably be a good solution IMHO. I was too afraid to propose that, but since it's now on the table....

[forki]

yes. things will break over time if we don't. We already saw that before we commited lock files.

[nojaf]

I would just add ~ for each package no?

[forki]

Yes but then you are making it harder for a user to update eventually. They will wonder why stuff is pinned

[MangelMaxime]

I am in favor to keep the "standard" lock file.

Because we want to be sure that it's working the first time someone use the template.

Imagine you are discovering a new project and the official template do not work. Then you will simply move to another project in general because it will feel buggy.

[forki]

even ~ has a big chance of breaking over time.

[MangelMaxime]

Wait why is paket removed from the template ? @nojaf

We are only locking only the JavaScript depencies and this is not good.

[forki]

yeah that's really weird....

[nojaf]

Well not to point fingers but @alfonsogarciacaro remove paket, I left it as is.
~ contains only revisions not? But then again in JS land, revision, minors, majors its all the same for those people 😅

See 2f0810f#diff-689e8e85f2010aa1303307034d9c1187, I believe the minimal sample is just copied.

[alfonsogarciacaro]

My purpose with the minimal sample/template is just to show a barebones Fable app with the minimal files needed to run everything. The README contains pointers to more comprehensive examples. Talking to people, I've noticed that users interested in the fullstack go directly to the SAFE template, so it's ok for the Fable template to keep things as simple as possible.

Unfortunately, the current situation around dotnet/F# tooling is extremely complicated and I'm afraid it may confuse newcomers (it confuses me):

• Fable installs as a DotnetCliTool (currently deprecated)
• Paket installs as .NETFramework .exe (needs mono) that's downloaded in the background from Github. Needs two extra files (build.cmd and build.sh) in two different scripting languages that you need to know about in some situations (e.g. to disable paket restore when you're running a build on a plane as the bootstrapper fails if there's no connection).
• I've already lost count of how many ways there are to run FAKE 5...

I probably should open an issue for discussion about this in the Fable repo.

@nojaf npm recommends to commit the package-lock.json file. I know it's big but it's probably better to go the standard way. The file is going to be created anyways as soon as users run "npm install". Also, yes, I copied the contents from the minimal sample and added a script to do that automatically. I was editing the README but thought that, as the template and the sample were so similar, it would be easier to just maintain a single code base and copy/link the other one :)

[forki]

Tbh I don't think removing paket improves the situation at all. It's just yet another setup that we need to test, support and explain. We can't point to one documentation anymore because "actually in that project things work differently". Part of the safe initiative was to come up with a canonical way of doing things so that we as community can share that knowledge easily. I know you want to make things easier for newcomers, but I don't think this is what we get here. Just my 2 cents Am Di., 13. Nov. 2018, 11:13 hat Alfonso Garcia-Caro < [email protected]> geschrieben:

…

My purpose with the minimal sample/template is just to show a barebones Fable app with the minimal files needed to run everything. The README contains pointers to more comprehensive examples. Talking to people, I've noticed that users interested in the fullstack go directly to the SAFE template, so it's ok for the Fable template to keep things as simple as possible. Unfortunately, the current situation around dotnet/F# tooling is extremely complicated and I'm afraid it may confuse newcomers (it confuses me): - Fable installs as a DotnetCliTool (currently deprecated) - Paket installs as .NETFramework .exe (needs mono) that's downloaded in the background from Github. Needs two extra files (build.cmd and build.sh) in two different scripting languages that you need to know about in some situations (e.g. to disable paket restore when you're running a build on a plane as the bootstrapper fails if there's no connection). - I've already lost count of how many ways there are to run FAKE 5... I probably should open an issue for discussion about this in the Fable repo. @nojaf <https://github.com/nojaf> npm recommends to commit the package-lock.json file. I know it's big but it's probably better to go the standard way. The file is going to be created anyways as soon as users run "npm install". Also, yes, I copied the contents from the minimal sample and added a script to do that automatically. I was editing the README but thought that, as the template and the sample were so similar, it would be easier to just maintain a single code base and copy/link the other one :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNCl8LzE-HS7it5KAlE7yBAVcqQuOks5uupsxgaJpZM4YbBI0> .

[MangelMaxime]

to disable paket restore when you're running a build on a plane

I don't think that there is much people programming from a plane for their daily work 😄

I know you want to make things easier for newcomers, but I don't think this is what we get here

I agree with what @forki said because if user goes to another repo he will see the different configuraiton files. Same if someone come to gitter and ask how to add a package to the repo I will say use paket. But if he doesn't have it, then he will need to set everything by himself which is worst IHMO.

I've already lost count of how many ways there are to run FAKE 5...

I don't really see that as a problem, maintainers should explain in the README.md how to use/run their project and so FAKE included.

[alfonsogarciacaro]

The problem is that Fable (and I as a core maintainer) is becoming a proxy of too many things. I have to a maintain the compiler which is already a complex project but also for everything that comes under the fable-compiler GH org I become the ultimate person in charge (answering issues, keeping docs and packages up-to-date, etc), and that includes being the face of many other tools that I don't control: npm, yarn, Webpack, React, FAKE, Paket...

I'd be more than happy to deprecate the templates (actually I was about to, there's only another one for Electron but doesn't seem to be maintained anymore) and just redirect people to the SAFE or Fulma templates. Should we do just that?

[alfonsogarciacaro]

Ok, let's do that! I'm more than happy to lighten my maintenance load :)