Fix circular dependency and update final-form

[ChrisOgden]

• Upgrade final-form to v4.20.1 to remove controversial dependency
• Change index.js for circular dependency issues when using inside another project

[ChrisOgden]

These changes were made prior to your latest code. I can either work through the conflicts or let you. I haven't had a chance to look at your changes in depth yet.

[TylerRick]

Hey, Chris, thanks for this PR!

Yes, sorry, my dev branch is still in constant flux (and subject to a lot of commit amending/rewriting) right now, so I'm not surprised there were a lot of merge conflicts, even for such a simple change.

You may want to hold off on any PRs for now, other than ones that add new examples ✨ 😀 ...

---

Circular dependencies

I had seen these warnings from rollup:

(!) Circular dependencies
src/index.js -> src/useForm.js -> src/index.js
src/index.js -> src/useForm.js -> src/useFormState.js -> src/index.js
src/index.js -> src/Field.svelte -> src/index.js
src/index.js -> src/Input.svelte -> src/index.js
src/index.js -> src/arrays/index.js -> src/arrays/useFieldArray.js -> src/index.js

but since it seemed to build and work fine as-is, and since I don't see any circular dependencies present in the dist/index.mjs module that consumers will actually be importing from, I don't think this is an actual problem at the moment — more like just a warning of a possible problem.

As such, I've just been treating those warnings as something to ignore for now. (See also these examples of other people knowingly having circular dependencies and choosing to ignore the warnings.) You're probably right that we should address them at some point though. As long as we can do so cleanly...

But I'd much rather have something concise like this:

  import { useField, Input, useForwardEvent } from '.'

than have it verbosely list out each individual "actual" source file path like this (which is longer to type, less maintainable, creates more duplication, causes more churn, and makes for more relative paths that need to be updated if any files get moved around):

  import { default as Input } from './Input.svelte'
  import { default as useField } from './useField'
  import { useForwardEvent } from './useForwardEvent.js'

So I'd prefer to find a different solution to those circular dependencies.

I'm thinking... instead of importing directly from our main index.js module, we just import from a internal module instead. This pattern was described pretty well here and here is an example of such a refactoring. What do you think?

Dependency upgrade

As far as the dependency upgrade, sounds great!

I've cherry picked that commit and will push it up soon.

[ChrisOgden]

Looking at this again I agree the circulate dependency items can be ignored for now, it stuck out to me when doing development and I think it is only occurring because I am using yarn:link to work with this repo currently. I believe if it was using the build folder it wouldn't have this problem.