Update the transpilation targets of the various packages
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"anderasableSyntaxOnly: trueimplies that we can removeimportHelpers: trueandtslibdependencies (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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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