Turfjs / Turfjs/turf

Update the transpilation targets of the various packages

Open
#2,989 12 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
10.5k
Forks
1k
Avg merge
1h 11m
Merged PRs (30d)
4

Description

The next time we make a major version change, I'd propose that we make the following changes around platform support.

All packages will ship "main" and "module" targets that can potentially use any syntax. We will change TypeScript to target esnext, and reserve the right to roll forward to any new syntax supported by TypeScript at any time even without a major release of Turf itself. Our own CI will still limit us from introducing syntax newer than the Nodejs versions in our support matrix.

For @turf/turf, there is an additional "browser" target, where we currently transpile with Babel. Currently that is set to use "targets": "> 0.25%, last 2 versions, fully supports es5, not dead". I propose that we change that instead to "targets": "since 2024-01-01", which gives us browser support for anything released in the last 2 years or so, but forces less transpilation including the important jump to es6 syntax.

In our CI we should drop any unsupported Node versions, and remove them from official support in the library as well.

We can also drop all of the escheck guarding, since we are shipping esnext syntax instead (and turf.min.js would be guarded by Babel anyhow).

The outcomes here would be:

  • Turf webapp consumers must transpile @turf/* packages in their bundling process for their own browser targets
  • Bundles being created are as small as possible with the newest possible syntax
  • target: "esnext" and erasableSyntaxOnly: true implies that we can removeimportHelpers: true and tslib dependencies (I think)
  • turf.min.js can use much more modern syntax, but nothing too recent. Interestingly this doesn't seem to save much overall space in the final bundle, which is still largely dominated by @turf/jsts.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the package transpilation configurations, the CI Node.js support matrix, the Babel browser target, and the escheck setup. Confirm the intended TypeScript targets and supported Node.js versions, then verify that all package builds, browser output, and CI checks reflect the new policy.

Written by the indexing model from the issue text.

Assessment

Tech stack
babel, nodejs, typescript
Domain
build-system
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.