Migration to pnpm and improved exports strategy

[smallsaucepan]

Another tranche of changes designed to modernise the build:

• Migrating repo from old yarn to modern pnpm
• Improved our exports strategy to better support both CJS and ESM
• Using named exports / imports within Turf (keeping default exports for now)
• Dropping support for ie11

NOTE couldn't get monorepolint working with pnpm, so it is currently disabled. MRL project shows signs of recent activity so will revisit with a more recent release in the near future.

Fixes #2553 and fixes #2260.
Also fixes #2307 though that was really remained open for discussion purposes.

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Have read How To Contribute.
• Run npm test at the sub modules where changes have occurred.
• Run npm run lint to ensure code style at the turf module level.

[favna]

Migrating repo from old yarn to modern pnpm

Any particular reason to not go from old yarn to modern yarn? As in, Yarn v4. To use one of the copypasta tags from my Discord server:

Click to expand, includes all the info and copypastable commands for switching to it

Yarn v4 is a new version of Yarn that we recommend switching to as Yarn v1 has long since been deprecated.

"But I don't see any update on [source]?"

That is correct. Yarn v4 is installed through Yarn itself. You configure Yarn v4 on a per-project basis. How you installed Yarn globally is largely irrelevant to this (corepack, volta, something else). How to install Yarn v4 for your project? Simply write:

yarn set version berry

This will download the new Yarn v4 binary and put it in .yarn/releases, you should push this to your Git repository. It will also create a .yarnrc.yml file which configures the path which you should also commit.

Next you probably also want to run the following 2 commands:

yarn config set enableGlobalCache true
yarn config set nodeLinker node-modules

This will add to your .yarnrc file:

enableGlobalCache: true
nodeLinker: node-modules

This ensures you have a more traditional experience with node_modules and a global cache.

The next step is to nuke your node_modules and yarn.lock and run yarn install

Then some final adjustments. Put this in you .gitignore:

# Yarn files
.yarn/install-state.gz
.yarn/build-state.yml

And anywhere in your scripts in package.json where you use * you should wrap it in extra "
For example:

{
	"format": "prettier --write \"src/**/*.ts\""
}

Mind you this last thing is a good thing to add regardless of script runner/package bundler because it ensures the glob is performed by the library and not by your shell, which may differ when people develop on different operating systems.

In short, the command to set everything up you can run:

yarn set version berry && yarn config set enableGlobalCache true && yarn config set nodeLinker node-modules && echo "" >> .gitignore && echo "# Yarn files" >> .gitignore && echo ".yarn/install-state.gz" >> .gitignore && echo ".yarn/build-state.yml" >> .gitignore

Ultimately Yarn v4 is

• Faster than Yarn v1, pretty much on par with pnpm
• Is very configurable
• Documentation is phenomenal
• I don't know how it works with pnpm as I don't use it but keep in mind that with Yarn you need to run yarn npm publish as opposed to npm publish so Yarn resolves workspace:^ dependencies before publishing since that's obviously not valid for the npm registry. I assume for pnpm you'd need pnpm publish as well.
• Still sticks to node_modules. pnpm with their pnp module has some weird things from time to time in specific project stacks, such as when module augmenting with TypeScript of transitive dependencies and pnpm doesn't link the transitive dependencies to node_modules.. yeah it's a bit of a PITA sometimes. Probably doesn't affect Turf but personally it has really annoyed me about pnpm.

FWIW I'm not really sure what your status is in relation to the Turf org but I imagine the chances for the PR to get merged are far far higher by sticking to Yarn.

[smallsaucepan]

Thanks @favna. Ha ha I did have a yarn 4 PR almost ready though couldn't get it to work with GitHub CI (something corepack related). About the same time another of the Turf team mentioned we weren't necessarily married to yarn. So to get a release out asap just went with pnpm instead.

Perhaps we will revisit yarn down the track. Things like constraints would be nice, though might also take a look at syncpack.

Noted your comments about releasing too. Will keep an eye on that as we go.

[favna]

GitHub CI (something corepack related)

I'm curious to know what. This is not something I ever experienced. I always just use setup-node action and then just run yarn install --immutable (equivalent of yarn install --frozen-lockfile). Are you perhaps misunderstanding how Yarn v4 is installed and configured?

TL;DR of the collapsed content above, you install Yarn v4 on a per-project basis and the binary gets put in the .yarn/releases directory which you're supposed to check into Git. Then the global Yarn, whichever version that may be is irrelevant, knows to look for the .yarnrc.yml file and the yarnPath config in there and use the binary as specified by the path.

This has the great advantage of ensuring that every developer on the project uses the same toolchain and same version, thus ensuring that there are no discrepancies on that part when trying to help your co-workers*. As an anecdote of sorts, in the past I've had colleagues working on Linux while most of us worked on MacOS and whenever the Linux colleagues ran npm install the package-lock.json would change in terms of URLs, versions resolved and whether http or https was used even though we were using the same versions of Node and Npm. Thanks OS differences... never again for me, please.

* I also do Java development and for this reason, I also much prefer Gradle over Maven because it has the exact same advantage

Aanyywaayy, ultimately do as you please of course. It's your project at all and it sounds like you guys talked about it well enough so I won't butt in further.

[smallsaucepan]

Are you perhaps misunderstanding how Yarn v4 is installed and configured?

Oh, that is entirely possible 😅 The v4 PR was #2551 if that's of interest, and the CI corepack problem is being tracked in an open issue in actions/setup-node (actions/setup-node#531)

Aanyywaayy, ultimately do as you please of course. It's your project at all and it sounds like you guys talked about it well enough so I won't butt in further.

No, this is all good intel and welcome any time. Even if we don't use something right away it's good to know what sort of things to look out for.

[mfedderly]

This is a huge amount of work. Thank you!

[mfedderly]

Does this work with .ts modules?

[smallsaucepan]

You mean "documentation lint"? Good question. I'll check and we can include turf-*/index.ts as a seperate change.

[mfedderly]

We might consider marking these all as @deprecated (in another PR) if we're intending to remove them eventually