Move cloudinary, unsplash and oembed out of fields package and oembed-adapters into new fields-oembed package

[MadeByMike]

Lots of files moved around here but not functional changes. I'm trying to consolidate the "core field packages" and isolate them from other field types. I intend to make this distinction clearer in docs in a future PR.

Moved @keystonejs/fields-cloudinary-image, @keystonejs/fields-unsplash and @keystonejs/fields-oembed out of the core fields package @keystonejs/fields.

[changeset-bot]

🦋 Changeset is good to go

Latest commit: 836079c

We got this.

This PR includes changesets to release 32 packages

Name	Type
@keystonejs/oembed-adapters	Major
@keystonejs/fields-oembed	Major
@keystonejs/fields	Major
@keystonejs/fields-cloudinary-image	Major
@keystonejs/fields-unsplash	Major
@keystonejs/fields-authed-relationship	Patch
@keystonejs/fields-auto-increment	Patch
@keystonejs/fields-wysiwyg-tinymce	Patch
@keystonejs/fields-mongoid	Patch
@keystonejs/cypress-project-basic	Patch
@keystonejs/demo-project-blog	Patch
@keystonejs/app-admin-ui	Patch
@keystonejs/auth-passport	Patch
@keystonejs/auth-password	Patch
@keystonejs/fields-color	Patch
@keystonejs/fields-content	Patch
@keystonejs/fields-location-google	Patch
@keystonejs/fields-markdown	Patch
@keystonejs/keystone	Patch
@keystonejs/list-plugins	Patch
@keystonejs/demo-custom-fields	Patch
@keystonejs/demo-project-meetup	Patch
@keystonejs/demo-project-todo	Patch
@keystonejs/cypress-project-access-control	Patch
@keystonejs/cypress-project-client-validation	Patch
@keystonejs/cypress-project-login	Patch
@keystonejs/cypress-project-social-login	Patch
@keystonejs/api-tests	Patch
@keystonejs/benchmarks	Patch
@keystonejs/example-projects-nuxt	Patch
@keystonejs/example-projects-starter	Patch
@keystonejs/example-projects-todo	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[jesstelford]

Even though this is a major, can we export some dummy "fields" with the old names that simply throw new Error('This field has moved to @foo/bar')? That'd make updating / migrating much simpler than unexpected missing exports.

[MadeByMike]

Even though this is a major, can we export some dummy "fields" with the old names that simply throw new Error('This field has moved to @foo/bar')? That'd make updating / migrating much simpler than unexpected missing exports.

Yes, 100%. I was hoping to be able to continue to export the fields package with a deprecation warning, but circular references.

Adding dummy fields is a next best option.

[JedWatson]

Found a documentation mishap.

Aside from that, I'm strongly in favour of also extracting the Location field since (like these others) it's tightly coupled to an external service provider (Google) -- let's turn that into fields-location-google (following our fields-content-tinymce convention, you could have other location fields backed by other services)

We used to have a Location field in keystone 4 that had support for Google but was also useful independently; the Location field in keystone 5 specifically stores a googlePlaceID field so I don't see it as belonging in the core set.

Might as well include that in this breaking change set.

Also, our Content field package is currently mis-named; should be fields-content not field-content. Given the theme of this PR/release, might be a good time to deprecate the misnamed package and publish the new one?

[timleslie]

This all looks good to me 👍

Addressed