Feedback wanted: Dropping CJS support entirely?

[mfedderly]

Does anyone have a use case where an esm-only version of Turf (released as 8.0.0) would cause problems?

From a maintainability standpoint it would be nice for us to be able to ship esm-only as it makes the build tooling much simpler.

I'm thinking that anyone shipping their own web bundle can use ESM only as most of the bundlers have supported ESM for many years. I'd be curious from the Node consumers whether this impacts your use, or whether the support for loading these modules with require handles it transparently.

[mfedderly]

cc @Brennan-Mckinney-Work

It seems like you were bitten by an esm-only package in the Turf transitive dependencies (#3018 (comment)), do you have additional information to share here?

I'd really like to drop support for Node 18 and 20, which are both EOL. Github actions are starting to complain about using Node 20 and I'm not sure how much longer it will work reliably. Moving to Node 22 also gives us the ability to run TypeScript code natively, which is really nice for our test/bench scripts.

Moving to esm-only also lets us remove a bunch of build tooling. We currently use the deprecated tsup, and the PR to replace its functionality with standard calls to TypeScript is quite large and could be avoided with ESM-only packaging.

If some users are stuck on EOL Node runtimes, I think it can be pretty reasonable to provide security support for the 7.x branch that fixes any warnings around Turf packages or their transitive production dependencies (something like pnpm -r exec pnpm -P audit for us), but starts to fall behind in terms of the correctness fixes. An example here is that great-circle could use an upgrade of its arc dependency, but that brings in ESM-only code which needs to be worked around (#3048).