Getting Turf back on track

[tmcw]

The goal for Turf v3 was to create a system in which Turf could be coordinated as a set of modules, operating independently but uniform in style, management, and properly versioned together. Unfortunately, that's no longer the case: the current codebase is heterogenous, hard to contribute to, and the guidelines for releases are nonexistent.

About half of the modules are in TypeScript, and about half of those modules have a tsconfig.json file. About 40% of modules name their main export main, and the rest call it index. Same with providing a module entry point, it's about 50%. 3 modules have a .mjs module file, the rest have .es.js.

Basically, there are no real homogenous properties of Turf anymore. It's a worst-case scenario for a mono-repo: it makes Turf maintenance feel much more like 'maintaining 55 modules' than it does 'maintaining a mono-repo'.

Turf modules summary

name	tsconfig	main	module	in ts
turf		turf	turf.mjs	👍
along	👍	index		👍
angle	👍	index		👍
area	👍	index		👍
bbox	👍	index		👍
bbox-clip	👍	index		👍
bbox-polygon	👍	index		👍
bearing	👍	index		👍
bezier-spline	👍	index		👍
boolean-clockwise	👍	index		👍
boolean-concave	👍	index		👍
boolean-contains	👍	index		👍
boolean-crosses		index		👍
boolean-disjoint	👍	index		👍
boolean-equal		index		👍
boolean-intersects	👍	index		👍
boolean-overlap		index		👍
boolean-parallel		index		👍
boolean-point-in-polygon	👍	index		👍
boolean-point-on-line	👍	index		👍
boolean-touches		index		👍
boolean-valid		index		👍
boolean-within		index		👍
buffer		main.js	main.es.js
center		index		👍
center-mean		index		👍
center-median		index		👍
center-of-mass		index		👍
centroid		index		👍
circle		index		👍
clean-coords		index		👍
clone	👍	index		👍
clusters		index		👍
clusters-dbscan		index		👍
clusters-kmeans		index		👍
collect		index		👍
combine		index		👍
concave	👍	index		👍
convex	👍	index		👍
destination	👍	index		👍
difference		index	index.mjs
directional-mean	👍	index		👍
dissolve		main.js	main.es.js
distance		index		👍
distance-weight	👍	index		👍
ellipse		main.js	main.es.js
envelope		main.js	main.es.js
explode		main.js	main.es.js
flatten		main.js	main.es.js
flip		main.js	main.es.js
great-circle		main.js	main.es.js
helpers	👍	index		👍
hex-grid		index		👍
interpolate		main.js	main.es.js
intersect	👍	index		👍
invariant	👍	index		👍
isobands		main.js	main.es.js
isolines		main.js	main.es.js
kinks	👍	index		👍
length	👍	index		👍
line-arc	👍	index		👍
line-chunk		main.js	main.es.js
line-intersect	👍	index		👍
line-offset		main.js	main.es.js
line-overlap		index		👍
line-segment	👍	index		👍
line-slice		main.js	main.es.js
line-slice-along		main.js	main.es.js
line-split		main.js	main.es.js
line-to-polygon		index		👍
mask		main.js	main.es.js
meta		index	index.mjs
midpoint		main.js	main.es.js
moran-index	👍	index		👍
nearest-neighbor-analysis	👍	index		👍
nearest-point	👍	index		👍
nearest-point-on-line		index		👍
nearest-point-to-line	👍	index		👍
planepoint		main.js	main.es.js
point-grid		index		👍
point-on-feature		main.js	main.es.js
point-to-line-distance	👍	index		👍
points-within-polygon		main.js	main.es.js
polygon-smooth		main.js	main.es.js
polygon-tangents		main.js	main.es.js
polygon-to-line	👍	index		👍
polygonize		main.js	main.es.js
projection		index		👍
quadrat-analysis	👍	index		👍
random	👍	index		👍
rectangle-grid		index		👍
rewind		main.js	main.es.js
rhumb-bearing	👍	index		👍
rhumb-destination	👍	index		👍
rhumb-distance	👍	index		👍
sample		main.js	main.es.js
sector		main.js	main.es.js
shortest-path		main.js	main.es.js
simplify		main.js	main.es.js
square		main.js	main.es.js
square-grid	👍	index		👍
standard-deviational-ellipse		main.js	main.es.js
tag		main.js	main.es.js
tesselate		main.js	main.es.js
tin	👍	index		👍
transform-rotate		main.js	main.es.js
transform-scale		main.js	main.es.js
transform-translate		main.js	main.es.js
triangle-grid		index		👍
truncate		index		👍
union		index		👍
unkink-polygon		main.js	main.es.js
voronoi		main.js	main.es.js

---

Organizationally, Turf currently has a small chunk of cash, a much much smaller number of long-term maintainers, and zero institutional/company code contributors. This is pretty common for open source projects.

To propose a few ways forward:

Remove TypeScript

The TypeScript transition, while a very nice contribution, is unfinished and offers little to the project. We didn't have many bugs caused by type mismatches before, and the resulting addition of complexity outweighs the benefit.

Would this be unpopular? Probably! But it'd be better to re-achieve stability and releasability, and make the project fit its actual contributors, than to perpetually be in a half-deployable state.

If this is the option, we could do it by basically configuring tsc to generate ES modules.

Move lerna.js back to fixed/locked mode

Per #1247 the lerna config was switched to independent versioning. This makes collaboration harder: the intent of lerna was and is to make versioning automatic so that the project can be released always with lerna publish. There should not be a thought process for which modules need updating and releases.

Move releases/ back into changelog

This releases directory is the same as a central changelog. Let's move these back to the changelog.

Use standard commits

Again, a common collaboration point - this will automate changelog generation and version more accurately

Write these contribution tips into CONTRIBUTING.md

And probably create a strong process for changing them. This stuff shouldn't become wobbly; Turf should stay in a deployable, simple state that all the maintainers have a grasp on.

(Extreme solution) just move to a singular ES6 module

This would probably be even less popular than removing TypeScript: create one turf module (again), now that tree-shaking means that people using Rollup/Webpack/Parcel can efficiently import a subsection of a module without including all of the code. This would drastically reduce complexity and let advanced users continue to get the performance advantages of the current mini-modules, but it would leave people using old-fashioned require etc out in the cold.

Honestly I'm also in favor of this extreme solution: it'd be a huge decrease in complexity, and it'd do this for existing users:

1. Script-tag or browserify users: yep, would be slower
2. Node users: probably don't mind the startup time or install size that much
3. Webpack/Rollup users: would work great
4. Future native-js module users: would easily be able to sub-import

---

This is intended to be a bit of a jumping-off point, none of these ways to victory are quick-fixes and we'd want to attain some consensus before embarking on them. Dividing this work up would also be useful, given that there are few maintainers, or if there is an institutional/company contributor who wants to take on some of this, it'd be more than welcome - Turf is definitely generating a lot of value out there in the world, much more than it captures.

[rowanwins]

Hi @tmcw

Thanks for taking the time to check in on the status of the project, this has certainly been weighing on my mind over the past couple of months.

That said I want to start by saying the following

• TurfJS has existed for the past few years largely on the back of the spare time, goodwill and interest of 3 people. This is important to recognise and thank - they've put in a huge effort and moved Turf forward a long way so thank you to my co-contributors @DenisCarriere & @stebogit 🙏
• Its worth remembering that in reality there are very few open source geospatial libs out there, and the bulk that exist piggyback on JTS, it's a great reminder that we're doing something that is complicated. We've also been doing it as volunteers in a JS world that is changing at great pace.

Re Typescript
I'd be supportive of ditching the typescript-first approach

1. We only have/had one active maintainer (out of the 3 at the time the decision was made) who knew anything about Typescript
2. The Typescript definitions we're using aren't compatible with what other common mapping libraries are using which kind of seems to defeat the purpose IMHO.
3. I can't think of any instances where I've had to provide support around people using incorrect geometry types for operations.
4. The previous approach allowed us to ship TS typings for those that were interested in using them but didn't make TurfJS all in on TS.

On a personal & professional note I have no desire or need to learn TypeScript, TurfJS would be my sole reason for learning it.

Re Lerna

1. Yep I think moving back to fixed versioning makes sense, this was working well in my opinion (eg the past few years until early this year).
2. The other note about lerna & publishing is that for the past few years it's always sat in the hands of one person, this obviously left a bit of a knowledge gap for the rest of the contributors. Lerna is it's own beast and while I've published many libraries via npm attempting to go through the process with Turf with lerna was/is scary for a first-timer for fear of breaking things

Contributing.md
Yeah agreed this is in dire need of an overhaul. Over the past 18 months there have been quite a number of changes to the various processes that have never been adequately captured.

Re All-in on ES6
So if I understand this correctly this would basically

1. do away with the need for lerna; and
2. npm would only contain a single turf package

Could you elaborate on use case 1 ('Script-tag or browserify users') - is that basically folks using Turf via a CDN? Why would that be slower under this proposal?

I think I cautiously support this approach. The bulk of browser apps (at least serious ones) are being built with some sort of bundling tool so I dont think we'd be leaving many out in the cold with this decision. My one proviso is that I think it would be nice to have some sort of basic bundled version (eg a CDN version) for people to hack with and learn with that doesn't require them to get into the whole world of bundlers, it wouldn't be the preferred method of usage but would be there to provide a low barrier of entry.

Anyway those are my initial thoughts - will ponder further and see if there is anything else that comes to mind.

Cheers
Rowan

[tmcw]

Could you elaborate on use case 1 ('Script-tag or browserify users') - is that basically folks using Turf via a CDN? Why would that be slower under this proposal?

If we were to publish a single ES6 module, then users who go through Rollup or Webpack would be able to do:

import {inside} from "turf";

And their application bundle would only include the code for the inside method and any of its dependencies. That's because of tree shaking.

But users who go through browserify, who would write

var inside = require('turf').inside;

Would get the full turf bundle, including JSTS, regardless of how much or little of the API surface they use.

And, well - now that I look at it, it looks like there aren't UMD bundles for individual parts of turf, so people using the CDN route would have the same experience: they'd always load the full library. So the only real drawbacks are:

1. For browserify users, bigger bundles
2. For people who previously just used @turf/someFunction, switching (back to) turf would mean a slightly bigger npm install. Which may be negated by the reduction in dependency tree size.

[Turbo87]

Use standard commits

[...] this will automate changelog generation and version more accurately

https://github.com/lerna/lerna-changelog would be another option, which generates the changelog from PR titles instead of commits

(Extreme solution) just move to a singular ES6 module

this seems like a good solution, but it would need to make sure that subdependencies are only imported by those functions that actually need them. e.g. the point() helper shouldn't import all of JSTS

Remove TypeScript

I'm not sure I understand why you want to remove TypeScript. It usually makes the APIs much clearer for users, even if there is no immediate advantage to the development of this project itself. External typings are an alternative but they tend to get out of sync and usually just don't work as well. Since TypeScript is mostly just a superset of JS it should work fine too for files without any type annotations, so even the current JS-only packages could be compiled with tsc.

Assuming things like #1297 can be resolved I'd prefer to keep/make TypeScript part of the project. I had mentioned before that I would be interested in helping move the project to TS, but I agree that in the current state it is hard to contribute to.

[tmcw]

this seems like a good solution, but it would need to make sure that subdependencies are only imported by those functions that actually need them. e.g. the point() helper shouldn't import all of JSTS

This isn't a current issue, right? For example, the point helper doesn't import JSTS.

I'm not sure I understand why you want to remove TypeScript.

The reasons are pretty clearly stated in the OP - we have very few contributors and they aren't TypeScript masters. Removing typescript would create a path to a once-again-deployable Turf.

Given more contributors, and contributors that knew TS inside and out, then TS would be a good idea, but we build projects with the contributors we have, not the ones we want. In other words, there is a disadvantage of TS to the development of the project itself - it's slowing down development.

If you want to push the TS move to completion, then - well - that'd be very welcome! I'm just reading the context, that the TypeScript migration kicked off in January, it's about halfway finished, and the main contributor of the TS parts isn't very active, so - given those priors, it's hard to anticipate a significant change.

[Turbo87]

This isn't a current issue, right? For example, the point helper doesn't import JSTS.

no, it's not. but if all implementations at the end were in a single file with a top level import it could become a problem, although given the amount of packages in this project it seems quite unlikely to be the endresult :)

given those priors, it's hard to anticipate a significant change.

sounds like a chicken-and-egg problem to me. if the project wasn't split into so many small packages, each with their own TS integration need, it would would be much easier to use TS for the whole project. and as I mentioned before, once TS is setup properly it can support both TS and JS and I'm assuming to support Node.js we would need something that compiles also to CommonJS anyway, right?

[tmcw]

Yeah, to be clear - 'a single ES6 module' means a single module published to npm, with a single entry point. It would not mean that all the code is in one file.

I'm assuming to support Node.js we would need something that compiles also to CommonJS anyway, right?

Yes, regardless of the path we take, we'd need to create a CommonJS entry point; that need doesn't go away unless we switch everything back to require(), which I don't think anyone wants to do. That step in the process isn't (imho) really a deciding factor - creating CJS entry points works with rollup, works with typescript, and plenty of other systems. If that were the main need, the most obvious solution would be something like Rollup, that we'll need to use anyway for creating a UMD bundle.

[stevage]

Thanks for starting this issue. For my part, I'm looking forward to contributing more. I don't have very much experience in packaging modules, and certainly not enough to make architectural decisions. But once we have a direction and a bunch of modules that need updating (in which ever direction) I'm happy to help with grunt work.

FWIW my perspectives on the key decisions:

Typescript

I was definitely not thrilled about using it, and it feels like a big barrier to any new contributor. (I suspect the actual barrier is less than the perceived one, based on my tiny experience, but that's a bit beside the point). It seems like the potential gains were fairly modest, the actual gains have been almost non existent, and the downsides are significant, so...pretty easy decision.

Single-module ES6

Personally, I still use Browserify, because it's what the dev tool stack I use uses, and I haven't had a compelling reason to switch to Webpack. I'm probably far from alone. So yeah, I'd be worse off. I'm not sure I'd even heard of "tree shaking" until this thread.

But honestly, the maintainability of the whole project is a much bigger consideration than bundle size for a subset of users. We should probably just make sure we alert potential users to this fact and maybe give them some useful pointers.

At the moment, it looks like the complete Turf bundle (via Browserify) is 557k. That's actually not that crazy. Still fine IMHO for people who are newbie web developers to just import the whole thing via a script tag. (I used to work on a website that shipped I think 7MB of JS at first page load so...yeah).

[tmcw]

Okay, well, if folks agree on those points, the path forward would be moving everything from packages to src, running tsc on everything consolidating all the deps and devDeps into a single package.json, rewriting cross-requires (import x from '@turf/meta' in other modules) into import x from ../meta', and so on.

---

Consider this an open task, if there's consensus on the way forward (on either part, the TS removal, single module, lerna arrangement, or just uniformity). My personal time, priorities, and interests don't line up here, so I'm not going to be contributing code or rejoining as a maintainer.

[stebogit]

I'm ok with removing TypeScript, cause for me as well it's kinda a barrier at the moment.

Regarding the structure, I trust @tmcw that a single ES6 module would drastically reduce complexity, and for ES6 modules I agree with @stevage, importing the whole library I don't think is a big deal.

However, to solve the import issue I was wondering if it was possible to automatically generate separate individual compiled files for each package/function, so that who wants/needs to use require or load on the browser to use one or more Turf functions could do that.
So we could have like:

import {pointGrid} from 'turf';

var pointGrid = require('turf/require/point-grid');

<script src="cdn/to/turf/scripts/point-grid"></script>

Is the above possible, if it even makes sense?

[Turbo87]

@stebogit require('turf/require/point-grid') won't solve the problem, as the file would still be part of the turf package with all its dependencies. you will need either a more advanced bundler or have a dedicated @turf/point-grid package like we currently have.

FWIW in theory it should be possible to still generate those single-module packages using e.g. rollup with generated entry files. I'm just not sure if that's worth the effort...

[tmcw]

That isn't correct: if you're using browserify or nodejs, and you sub-require a commonjs file within a package, like require('turf/require/point-grid'), then browserify will only include the files require()ed from that file in the bundle. See, for example, 101, a module that relies on that pattern extensively to let people include individual functions without pulling in the entire source.

[DenisCarriere]

@tmcw @stebogit @rowanwins I know I've been away for a long time, I've deep dived into the blockchain rabbit hole.

I'm 👍 if we drop Typescript, it was actually harder then I expected to convert the code base.

I can help refactor Typescript out of it, we should keep it ES6+ that way it works well with Rollup.

I'm 👍 if we convert it to a monorepo @turf/turf (not sure how much refactoring needs to happen with that).

[rowanwins]

So it sounds like we've got consensus on a desired way forward - thanks for the suggestions @tmcw and others for chiming in their thoughts.

I'm happy to take the lead on a pull request outlining the revised repo structure along the lines of what @tmcw has suggested above. I'll also include a couple of worked examples for modules. Hopefully once we've got the pattern sorted we might be able to work together to get some of the changes made at a steady pace. I'll try and aim to get something up in the next few days so stay tuned.

Given that this will be a substantial change we'll be releasing this as a new major version so this would be a good time to tackle any other breaking changes, for example addressing this one comes to mind.

[andrewharvey]

I agree with dropping TypeScript, it's a big barrier to entry for new contributors (one extra thing to learn).

If we were to publish a single ES6 module, then users who go through Rollup or Webpack would be able to do:
import {inside} from "turf";

That would be nice, as a developer using turf, a big annoyance is knowing which module a method is in. Is it in helpers, it's own module or meta... I'm constantly needing to check the docs on this.

I just want to import whatever methods I need from turf and then use them as turf.method, or if tree shaking works, then let it decide what to include in the bundle.

[stebogit]

Amen @andrewharvey! 😄

[DenisCarriere]

+1 Amen!

[stebogit]

Is my understanding we are going to build the final bundle using Rollup (or some other bundler), correct?
Then why don't we include Babel (or similar) in the build process and switch to ES6 syntax as well?
That would modernize the code and open the door to future developments of the language.

We don't need to convert the entire codebase now, that can be done bit by bit at any time or just if/when a module needs to be fixed or modified. But since we are restructuring the project I suppose this would be a good time to introduce that upgrade as well.

[tmcw]

The main Turf bundle is already generated with Rollup. It is, of course, the choice of the maintainers how to play it out, but at least from my perspective, using Babel would add complexity for little benefit. Turf is mostly low-level mathematical code with hot loops. Using syntax extensions would make testing more complex, introduce hard-to-anticipate performance problems, and make debugging error reports harder, because it would be debugging transpiled code and relying on sourcemaps, which rarely work well.

[stebogit]

@tmcw that is a very interesting prospective I could have never thought about
You are probably right, we might not want to switch to ES6 at this point.

NOTE: is this a good site to check to see when ES6 will replace ES5 as the new standard JS? I mean what't the best way to learn when that will become official?

[tmcw]

That's a pretty good resource. Really the good news is that a lot of ES6 features are supported well enough that something like Babel isn't required. My day job (⦿) writes ES6+ code and deploys it without a transpilation step - stuff like classes, let/const, async, generators, and so on all work in the last few major browser versions as well as node.

[Turbo87]

@stebogit there is also https://node.green/ that tracks what ES features are supported by the various Node releases

[danloiterton]

Hi guys,

Love turf. Fantastic library. Many thanks for your efforts!

I stumbled across this thread trying to debug an issue using require. I haven't used the library for a little while and just downloaded @turf/truncate 6.0.1 and tried to const truncate = require('@turf/truncate'). It doesn't work. I get TypeError: truncate is not a function when I try to call it.

Instead I need to use const truncate = require('@turf/truncate').default, which seems a bit weird. Not sure if it's a bug or intended? I'm assuming it works fine with import truncate from '@turf/truncate'.

Anyway, as a developer, I only really use turf in node.js data processing scripts (a little bit in my node/express back end, and not at all in my React front end). We use babel for our back end code so that we can use ES6+, import/export, etc. But with the scripts, it's really nice not having to transpile anything.

Just thought I'd add that feedback in light of your current decision-making

[AbelVM]

Hi, just my two cents.

I've been playing with JavaScript since v1.1, not kidding, Netscape times, you know! And I'm not a foreigner in ES6+ country. But I'm definitely not an architect, I just use the code as a tool to solve a problem, geospatial problem in this very case. So, I'd love to contribute with new modules, but I'm not an expert about the best way to mash-up and serve all the code involved here. I'm not here to give my opinion about the answer (which is 42 regardless the question), I just want to share my experience as a keen contributor and TURF lover, maybe more related to spatial-data-science than coding.

I contributed to TURF with several modules time ago, years I mean, some of them made their way into releases, some others were just deprecated with better versions or were just crappy. By those times, nodejs was alien to me, but I was flexible enough to adapt my vanilla code to node modules with just a couple of lines of code. Node is not that hard for this purpose.

Now that I'm somehow back, I feel like a noob. Yesterday, I spent the morning porting a classic ESRI's GIS function to TURFJ. It was quite easy, once I already had it ported to SQL and running in production environment, so it was somehow like SQL -> ES6 translation, plus testing. The code worked, my tests were OK, but... BUT, when I tried to fulfill the TURF Contribution Guide requirements, it was just a nightmare. And I just needed to left it there and ask for help in an issue. Not only the Contribution Guide is unfinished and obsolete in some points, but also the mix of JavaScript, TypeScript, requires, imports,... I tried to follow the existing modules as guidance, but I couldn't find two of them following the same rules. So, my 2-3 h project, turned an 8h one, with not even a PR at the end because I couldn't run even the linter or the tests.

So, my two cents, finally: I'd go with the simplest way of all of them, the one that doesn't make potential contributors or maintainers run away when they dig in the gears. The one that doesn't make adding a new module a labyrinthic task. And, we're in 2018, a 500kb load in scripts is typically present in any website!

I must say, as a final note, that the boilerplate for new modules is such a great help!

[rowanwins]

Hey @AbelVM (& related to @danloiterton comments as well)

Yeah unfortunately the documentation for contributing to Turf, as well as doco for using Turf, both struggled to stay up to date at the beginning of the year when a bunch of changes happened and they've never caught up. Once the codebase is back in a more stable state I'll revisit them both.

[AbelVM]

I just wanted to highlight that the architecture doesn't only impact performance and package sizes. It might also discourage potential contributors if the process to add a new module is like untangling the Xmas lights.

[andrewharvey]

Instead I need to use const truncate = require('@turf/truncate').default, which seems a bit weird. Not sure if it's a bug or intended? I'm assuming it works fine with import truncate from '@turf/truncate'.

Just wanted to say I ran into too, in node.

[dbauszus-glx]

Are any of you at FOSS4G in Dar es Salaam at the end of the month? Turf development could be a good BOF topic.

[rowanwins]

Afraid not @dbauszus-glx - I'm in Australia so I'll likely present on it at FOSS4G Oceania later in the year

[garthk]

I'm 👎 for removing TypeScript.; we can contribute dev time to help keep it up to date if necessary.

Failing that, if you're locked into removing TypeScript, please take control of your own typings. (We can help with that, too.) If you leave it up to DefinitelyTyped, it's all too easy to end up with people making breaking changes in point releases.

[rowanwins]

Hi @garthk

Who is we?

Unfortunantly you're chiming in on an issue several months old and ive already done the bulk of the work to refactor to es6 modules - feel free to check out the v7 branch.

And i'll take whatever help is on offer with maimtainig the typings because i dont know how they are supposed to work :)

[garthk]

Anditi. We've got a few devs working against Turf. At least two of us are happy to edit typings and do some heavy lifting on refactoring to the v7 structure to get the project back on track. We also have a GIS greybeard to help make calls on accuracy issues like #1470. Speaking of, the MAJOR bump to 7 will let you fix #1470, which we'd prefer to having to maintain a fork of 4.7.3 for the rest of our lives.

[rowanwins]

Hey @garthk

Looks like a neat company (even Aus-based!) - glad to see people putting TurfJS to good use. And it would be great if your company was able to provide a bit of assistance in maintaining TurfJS given your commercial interest.

Yep v7 is indeed a major bump on purpose to let us introduce some major changes, amongst which I'm including some major fixes to buffer. The buffer module is also our final dependency on JSTS (a huge size impost on our codebase) so during our alpha period I'd like to look at rewriting this entirely.

And some input from GIS greybeards would be awesome - unfortunately a few decisions have been made in the past which have had unintended consequences so it would be great to lean on some advice in that space.

Would be good to followup via email just to say hello and fill you in a bit more about the current project context, I'll try and get an email to you in the next few days.

Cheers
Rowan

[garthk]

No worries; use gkidd@$DOMAIN or I'll never see it. For more real-time replies, try Twitter (@garthk) or Keybase (garthk). Let me know if there's a handy IRC, Slack, or if you use the Gitter that's already there. I'll let my co-workers stick their heads out as they see fit.

I don't suppose there's any appropriately licensed C++ out there you can run through emscripten to replace JSTS?

[rowanwins]

Thankfully after a few years hiatus Turf is back on track with a team of contributors helping on many fronts 🎉
We've now had a series of stables releases from v6.2.0 onwards.
Still a lot of work to be done but lots of good progress is being made.