Add support for cdn field

[porsager]

Now that the browser field will most likely be deprecated I think adding support for cdn if unpkg is not present would be the right thing to do.

Having to ask package maintainers to add multiple fields seems very unnecessary if cdn can cover 99% of the cases.

Maybe I'm missing something, but what are the cons of adding support for cdn?

[mjackson]

Hi @porsager, please see #63 (comment) and #63 (comment) for my thoughts on this. Basically, I haven't heard any proposal yet for a cdn field that makes any sense. The jsDelivr people want to rush to create a standard for something that isn't even specified right now, and I'd like to keep using the unpkg field so I'm free to innovate with it in the future.

FWIW the only people who seem to be pushing for this are the jsDelivr people who introduced npm support last month. We've been doing it for over 2 years here.

[porsager]

Hi @mjackson.
Yeah, I read through that entire thread, but thought the discussion of a cdn field or something like it got buried, and deserved it's own issue.

If you remove the support for the browser field there's really no vendor agnostic way to point to a "browser distribution" in package.json,

My thought when seeing the cdn suggestion was that it seemed like a proper suggestion, since it would allow package maintainers to easily decide which file in the package should be served from a cdn.

I'm not saying the unpkg field shouldn't exist, I just think it would be nice if there was a common field to support the "browser distribution" path, so package.json is kept neutral, and package maintainers won't have to add multiple cdn specific keys for the same value.

By the way, I love unpkg and use it every day - so thanks are in order as well ;)

[mjackson]

Sorry for being so slow to respond here. While I agree with you that the current package.json specs are limiting, I'm doing my best to not make the problem worse by implementing something that hasn't been thought through all the way here. I believe in the long run that will only do more harm than good.

For now, people can just use the unpkg field and we all can agree on what that means. When a new proposal for a better package.json gains some momentum, we can revisit.