What would be the use case here? Can you give an example?

I'm tempted to decline this PR, since exporting other libraries is rather bad form. Especially if it's just exporting one class of it. If you need http_parser code, you should depend on it. For dio, it's pretty much an implementation detail, and exporting it makes it no longer an implementation detail, and thus harder for us to evolve related things.

Yea, I don't think we use this class as parameter anywhere. If you want to use this for parsing mime/media types you should import this in your package.

Well, we accept MediaType as content-type in the multipart file.

But I agree that users should import the package explicitly.

I 100% disagree. Why should users have to add a dependency which is an implementation detail of dio just to use the API? Exporting types from other packages is a very normal thing to do and is common in popular packages.

I'm trying to find best practices for re-exporting packages from the package but failed to find something. Given that we have previous arguments about "best practice", I'm reopening this for further discussions.

Well, let's do it.

Should we document somewhere that we're re-exporting these classes, in case people will run into name conflicts? Is it even possible to run into problems?

What if we use a type alias with a Dio prefix and re-export that? It will still accept the original MediaType type so it should not break anything.

What if we use a type alias with a Dio prefix and re-export that? It will still accept the original MediaType type so it should not break anything.

That would be a great idea. @Reprevise Could you make that attempt?

I could do:

typedef DioMediaType = MediaType;

Though I prefer the exporting approach so that users would just get an unnecessary_import lint and its easier to migrate than having to change MediaType to DioMediaType.

They should not get any warning, the MediaType should still be an accepted argument.

They should not get any warning, the MediaType should still be an accepted argument.

Not saying they should get a warning, but I just mean if they want to get rid of the http_parser import and the explicit dependency of it in pubspec.yaml.

Those who care about removing the explicit dependency are free to change from MediaType to DioMediaType.
Everyone else is not effected.
And we prevent compiler warnings for duplicate types/exports.

I have updated to use the type alias. The reason I had the constructors take DioMediaType is to make it less confusing for newer users. Users who see MediaType will try and use it and it won't be available to them without first depending on http_parser whereas if they use DioMediaType it will instantly be available.

For me it looks good, can you maybe add a test which ensure that we can still pass the MediaType as argument? Or is that overkill?

One thing that I didn't consider is that when hovering over the constructor, it doesn't actually say the alias, it just says the type.

So even though I changed the constructor to take a DioMediaType, you'd only know that if you go to the actual declaration.

@Reprevise Could you solve the format issue?

@Reprevise Could you solve the format issue?

What format issue?

@Reprevise Could you solve the format issue?

What format issue?

https://github.com/cfug/dio/actions/runs/9175832587/job/25229693166?pr=2205

Code Coverage Report: Only Changed Files listed

Minimum allowed coverage is 0%, this run produced 81.41%