Fix path imports to be ESM compliant

[rsweeneydev]

Fixes #276

[changeset-bot]

🦋 Changeset detected

Latest commit: 699e20e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
bits-ui	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

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
bits-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 14, 2024 0:36am

[rsweeneydev]

There are some upstream issues exposed by moving to module: NodeNext. You'll see them when you run svelte-check.

1. melt-ui has similar issues with import specifiers missing file extensions.
2. All the icon imports from phosphor throw the error below when running svelte-check

Error: Argument of type 'typeof LockKeyOpen' is not assignable to parameter of type 'ConstructorOfATypedSvelteComponent'.

Possible causes:
- You use the instance type of a component where you should use the constructor type
- Type definitions are missing for this Svelte Component. If you are using Svelte 3.31+, use SvelteComponentTyped to add a definition:
  import type { SvelteComponentTyped } from "svelte";
  class ComponentName extends SvelteComponentTyped<{propertyName: string;}> {} (ts)
                                                />
                                                <LockKeyOpen
                                                        class="absolute right-4 top-[14px] text-dark/30 sq-[22px]"

[AdrianGonz97]

Thank you for the PR! I think we'll wait for the Melt PR to merge first (and hopefully a phosphor-svelte one soon after) before merging this one.

[saul-atomrigs]

@AdrianGonz97 Seems like the Melt-UI PR has been merged!

[AdrianGonz97]

Apologies for letting this sit for so long.

Due to how large of a PR this is, and how long we've let it sit for, the merge conflicts grew to so much, it was far easier to just reimplement this again rather than resolve every conflict.

Closing in favor of #352