feat: @floating-ui/utils package

[atomiks]

• @mihkeleidast which functions were most important to export? I haven't exported every util from each package here
• Should dom-based utils and pure/core-based utils live in the same package? Wonder if there a problem with types or if you can import them from any environment without issue...

[rollingversions]

@floating-ui/core (1.3.1 → 1.4.0)

Refactors

• Split utils into @floating-ui/utils package

@floating-ui/dom (1.4.5 → 1.5.0)

Refactors

• Split utils into @floating-ui/utils package (@floating-ui/utils/dom import)

@floating-ui/react (0.24.8 → 0.25.0)

Refactors

• Split utils into @floating-ui/utils package (@floating-ui/utils/react import)

@floating-ui/utils (unreleased → 0.1.0)

New Features

• Initial release

Packages With No Changes

The following packages have no user facing changes, so won't be released:

• @floating-ui/react-dom
• @floating-ui/react-native
• @floating-ui/vue

Edit changelogs

[netlify]

✅ Deploy Preview for vibrant-gates-22c214 canceled.

Name	Link
🔨 Latest commit	e38a5a4
🔍 Latest deploy log	https://app.netlify.com/sites/vibrant-gates-22c214/deploys/64c37046ce3bce00081979a5

[mihkeleidast]

My main idea with this was to make debugging and testing changes in some of the middleware/hooks easier by allowing to essentially copy-paste the source (= 1 file) from this repo to my own codebase and not have to do too many additional changes manually. Looking at this, it makes it somewhat simpler if at least some of the hooks are from a separate package, but there are still plenty of such utilities used in some of the hooks, which would require additional manual copy-pasting and changing.

[FezVrasta]

It would probably make sense to have a @floating-ui/utils/dom import for the DOM-based ones, otherwise most of them will make non-DOM environments error

[atomiks]

@floating-ui/utils/dom

I don't know the best way to package that type of import with wide bundler support, namely ones that don't support "exports" 😞 - just a dom.js file? I know the dom/package.json subfolder technique works

Another issue is the dom UMD file should remain lean, and this introduces exports in it that are unused.

[atomiks]

My main idea with this was to make debugging and testing changes in some of the middleware/hooks easier by allowing to essentially copy-paste the source

I guess the exported modules should be what's most frequently used to build the middleware or hooks in the package internally then. That would make custom hooks and middleware easier to write. Won't be a perfect 1:1 match though

[FezVrasta]

I would also suggest to keep this package under 0.x.x so that you can introduce breaking changes as needed. Otherwise you'll be forced to release majors every time some internals change

[atomiks]

Made these changes:

• @floating-ui/utils contains environment-agnostic utils. Basically pure string manipulation or math-based functions, etc
• @floating-ui/utils/dom sub-path contains DOM positioning-based utils needed for the dom package
• @floating-ui/utils/interactions sub-path contains DOM interactions-based utils needed for the react package. (Not sure on this name). Some of them aren't "interaction"-y but aren't needed for the DOM package, which lets the UMD file be smaller for @floating-ui/dom

They'll be versioned at 0.1.x. 0.0.x means patch releases are considered breaking, so then every dependant needs to upgrade instead of letting the versioning remain transitive for patches. Minor bumps means the dependants need to release as well though.