Remove and deprecate Fable.PublishUtils

[MangelMaxime]

Description

Fable.PublishUtils consist on list of utility tools which are used to release some of Fable packages.

It was created a long time ago because FAKE and other solution were considered too complex to put in place.

Today, with projects like Fun.Build, EasyBuild I think Fable.PublishUtils don't make much sense.

Also no one is really maintaining it, for example myself I invested my time in EasyBuild ecosystem.

For this reason, I think we should just delete the folder and mark the project as deprecated on both NuGet and NPM.

PS: I believe Fable.PublishUtils is mostly used by project under Fable org, so if previous version breaks or need to be update to new tool chain I will make the upgrade.

[ncave]

@MangelMaxime I would respectfully disagree with deleting the Fable.PublishUtils project folder. If we want to deprecate the package in Nuget and NPM cause we don't want to maintain it, that's fine, but I think we can still use it internally in Fable. The less dependencies Fable has on external packages, the easier it will be to maintain it going forward. But that's just a personal opinion, feel free to disagree.

[MangelMaxime]

@ncave Fable.PublishUtils is not used by Fable release pipeline.

It is used by other repository inside of Fable org like fable-browser or Fable.Node. And I am planning to move these project to using EasyBuild because EasyBuild allows to generate changelog based on the git history and it make my life as a maintainer easier. I don't need to manually patch Changelog file etc.

So removing the folder would cause no harm. I wanted to remove the folder, to have 1 less folder to care about especially, if we don't plan to make a release for it anymore (it is saved in the fable4 branch if we need it for some reason).

[ncave]

@MangelMaxime

Fable.PublishUtils is not used by Fable release pipeline.

I know, that's why keeping it would cause no harm either. But if you feel really strongly about it, sure.
My personal preference is to keep things minimal and not introduce too many external dependencies.

In that line of thought, the current build system may be a bit too complicated to navigate and contribute to.
I'm just saying that in hope to attract future contributors we may want to keep things simple.

To clarify, I really appreciate your efforts and taking on the burden of publishing, and I want to help as much as I can. So anything that can simplify that task, I'm all for it, hopefully without introducing too many dependencies that we'll have to keep up with.

[MangelMaxime]

To clarify, I really appreciate your efforts and taking on the burden of publishing, and I want to help as much as I can. So anything that can simplify that task, I'm all for it, hopefully without introducing too many dependencies that we'll have to keep up with.

Thank you :) I think we both found our balance on working on Fable and I also appreciate your help and pointer regarding Fable internals.

In that line of thought, the current build system may be a bit too complicated to navigate and contribute to.
I'm just saying that in hope to attract future contributors we may want to keep things simple.

I agree with the build system being complex, with the rework of last year we have been able to mutualise a lot of code but this is not perfect.

From my point of view, the area where we can improve the build system is on the Publish target but this would also means adding external dependencies to the EasyBuild ecosystem which was build for such situations.

Indeed, EasyBuild consist of a set of tool to make common tasks easier for example:

• Using EasyBuild.PackageReleaseNotes.Tasks we will be able to remove the manual patching of fsproj to include <Version> and <PackageReleaseNotes> it will be done by just adding the dependency (as a dev tool, so it is not published dependency on NuGet).

  This will remove around 10 lines of codes and 3-4 files from the build system

• Using EasyBuild.Tools means that we will be able to remove the rest of the files under Utils folder and directly have access to common tools like DotNet.nugetPush, DotNet.pack, etc.

I will send a PR, to demonstrate what impact it can have on the build system and if we are okay with it with will merge it.

Regarding the other targets of the build system, I don't see an easy way to simplify them. Most of their comes from how Fable + the target ecosystem works.

I think my main idea here would be to mutualise the tests, so we could avoid writing 3 times the same test for Python, JavaScript, Rust. It would also helps with feature parity. I have some ideas regarding that but I need to do some experimentation.

---

The last step to make publishing even easier would be to use EasyBuild.ChangelogGen which is a tool which can generate Changelog based on the git history.

But this one is much more invasive, in the sense that maintainers need to respect the Conventional Commits spec. This is a spec that is really taking in now days as it allows changelog generation.

Regarding EasyBuild.ChangelogGen this is not yet a proposition, as I need to explain clearly how it works so everyone can make an highlighted decision.

[ncave]

Test are a different conversation, but yes, ideally we want a single test harness that works for all languages.
We'll have to do a lot of conditional work to get there though, as feature/API support differs a lot between languages.

That said, IMO reworking the test harness just for the sake of it (without adding features) is technically bike-shedding, cause it only adds value at the margins.

[MangelMaxime]

We'll have to do a lot of conditional work to get there though, as feature/API support differs a lot between languages.

Indeed, this is the big issue I see myself too.

Perhaps, with smaller/more focused test files this would be less of a problem but I am not sure.

The more I have been thinking about it, and the more I think it would need to be something progressive. We would still have a per target test project when a feature is being worked on / non stable or fully supported.

And once it reach a certain level, we remove it and make it use the shared tests to ensure feature parity. The idea being once, we reach feature parity fixing bugs or adding support for 1 new API/method if often not too difficult.