Split NuGet package into few child packages to ease dependencies

[abatishchev]

The idea is to extract few child packages:

• JwtNet.Json.NewtonSoft for JsonNet based implementation of Json (de)serialization
• JwtNet.Json.ServiceStack for ServiceStack.Text based implementations
• JwtNet.Cryptography.RS256 for System.Security.Cryptography based implementation of RS256Algorithm

[nbarbettini]

I like this idea, because it will mean that the "base" functionality can exist in a package that supports the widest number of platforms/devices. The only thing to figure out is how to structure the package graph to be both flexible and have easy discoverability.

For example, if you do install-package JWT, should you get JWT.Json.Newtonsoft automatically? It would be less confusing if you did, but if it's declared as a dependency of JWT, you won't be able to remove it.

One solution I've used in the past is to push all of the interfaces (and maybe base functionality) into a package called JWT.Abstractions or JWT.Core, and then make the top-level JWT package just be an empty metapackage that serves as an easy target for discoverability. That would look like:

JWT (empty package, just dependencies)
  - depends on JWT.Abstractions
  - depends on JWT.Json.Newtonsoft
    - depends on JWT.Abtractions

So, install-package JWT gives you the default packages. If you want to customize the installation, you can skip JWT and install JWT.Abtractions directly plus whatever supporting packages you want.

Any thoughts?

[abatishchev]

Sounds like a plan! I would just avoid calling it Core to avoid confusion with .NET Core. At work I usually call such project Contracts but we can make up something different.

Should we bump major version to 3.x since it'll be one more big breaking change.

[nbarbettini]

I would just avoid calling it Core to avoid confusion with .NET Core

Agreed 😄

Should we bump major version to 3.x since it'll be one more big breaking change.

I'm fine with that, would you want to fully drop the old static interface too?

[abatishchev]

Yes, I think that would be the right time to do it.

[zemien]

This looks like a great, easy-to-use library. I notice @abatishchev has started porting it to .Net Standard. Is there anything I can help with that process? I need something similar for my .Net Core project and I would rather help get this production-ready than do my own personal fork.

[abatishchev]

hi @zemien, the port is done (committed but not published yet). hey @nbarbettini, can you please pack and push to nuget?

[nbarbettini]

@zemien see the latest prerelease version (3.x series) on NuGet. That supports .NET Standard already. 👍

[zemien]

Awesome, I see it now, it's great work!

…

On Sat., 6 May 2017, 03:24 Nate Barbettini, ***@***.***> wrote: @zemien <https://github.com/zemien> see the latest prerelease version (3.x series) on NuGet. That supports .NET Standard already. 👍 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIBH-M6Xqqr-5mEeReTNyLae-TU5wJavks5r2z8_gaJpZM4Mr_b0> .

[nbarbettini]

Is this still something you'd like @abatishchev?

[abatishchev]

I'd park this since it seems there is no demand on implementations other than Json.Net. When/if such demand will be called out, we can come back on this. What do you think? Makes sense?