Split out Fsharp.Data.Json.Core etc

[cartermp]

The support matrix for this package is quite high, which makes adopting updates to things (tools, F# compiler) and contributions tricky and potentially error-prone. I think moving to NS 2.0 only, with a major version bump, might be good for the long-term health of the pakage.

[pimbrouwers]

Piggybacking on this, which I completely agree with. Maybe we move away from the single-package, in favor of separate smaller packages. For example: FSharp.Data.Html and FShar.Data.Json as separate packages.

[pimbrouwers]

For anyone interested, I've done this specifically for the Json functionality (provider and http functionality excluded). It was really quite painless.

https://github.com/pimbrouwers/FSharp.Data.Json

[cartermp]

@pimbrouwers the FSharp.Data.Json splitting out looks like a great idea. Splitting out each of the type providers would have some benefits:

• Perhaps a bit more clear which one you have
• In line with other packages using FSharp.Data in their name
• If someone is only using one, they are 1/4 less affected by this issue: Merely referencing FSharp.Data results in a nontrivial fixed cost to compile times dotnet/fsharp#7907

However, the downsides are somewhat large. Asking users to move from a single package like this into separate ones is quite a task for the large number of people who depend on this package.

Overall I'd be in favor of that kind of split, but I think more folks involved with this package would have to have a say

[pimbrouwers]

@cartermp brilliantly put. I agree on all fronts.

As far as the migration is concerned, perhaps there could be a deprecation period where the single & multi-package implementations are maintained in parallel. With the understanding that the single package would one day be deprecated.

Perhaps we tackle these problems separately:

• Work toward netstandard2.0 compliance.
• Once established, we can begin teasing apart the tentacles. A separate package for: JSON, HTML, CSV etc.
• Both implementations, single and multi, are maintained in parallel for a period.

[cartermp]

Curious what @dsyme thinks here.

[dsyme]

I think this would be great

[CaringDev]

... single & multi-package implementations ...

Or the existing package could be changed to a meta-package referencing all the new ones. This could even be done tentacle by tentacle.

[joshuapassos]

It's possible change multi-package ? Is there a roadmap for migration?

[dsyme]

I'm renaming this issue to be about splitting out FSharp.Data.Json etc

[toburger]

A welcome separation! I often use FSharp.Data solely for it's JSON utility functions.

[dsyme]

@pimbrouwers Could you give "fsprojects" ownership of the package "FSharp.Data.Json" please? We'd potentially like to use it here: #1457 , see https://www.nuget.org/packages/FSharp.Data.Json

[pimbrouwers]

Sure thing! Is this the correct method? If so, which account:

Or are you speaking about the NuGet package?

[dsyme]

@pimbrouwers The nuget package - I think you add "fsprojects" as org https://www.nuget.org/profiles/fsprojects

[pimbrouwers]

@dsyme done!

[pimbrouwers]

A welcome separation! I often use FSharp.Data solely for it's JSON utility functions.

@toburger might be worth checking out Jay, which is a fork of FSharp.DataJson with some optimizations and refinements. We use it a lot at the NHLPA with great success, you might find it useful as well!

[dsyme]

This is now merged and released as FSharp.Data 5.0.1