Turf: Consider adding new contributors?

[mfedderly]

It seems like Turf has received very little love in the past year. Are any of the core contributors still available to help look at PRs and Issues? Otherwise would you be open to adding new contributors to carry the torch forward?

I'm open to trying to help out. It seems like the first step is probably going through existing tickets and issues and at least getting releases flowing again. I personally would like to have standardized (and correct) typescript types across all of the packages.

Thanks!

// tagging some folks directly
@DenisCarriere @morganherlocker @tmcw @stebogit @muziejus @rowanwins @lyzidiamond @tcql

[tmcw]

That's true - I think this is two problems: both a lot of contributors dropped off, and we had a big "rewrite the world" project in the enormous v7 PR: https://github.com/Turfjs/turf/pull/1432

I think that:

1. #1432 is no longer viable for a real merge. It's multiple years old and there are tons of PRs after it that would all be crunched. We should close it, not delete the branch, and pull pieces after a round of basic maintenance.
2. happy to add other contributors, but I'm no longer an admin - @morganherlocker mind doing the honors?

[rowanwins]

Hi @mfedderly

Yep unfortunately Turf has become pretty stale over the past 12-18 months including my own contributions.

The biggest hurdle I see at the moment is how to run releases on the master branch. I know very little about publishing lerna packages. It seems like it should be straightforward if all packages are at the same version number but when they are not I'm not sure how to remediate or manage things. I previously asked for help from past maintainers and received next to nil, so I'm not sure if there is anyone willing and able to pick that up.

On a more positive note I've been quite active outside of turf writing modules which will benefit turf in the longer term

• sweepline-intersections (replace turf/kinks)
• point-in-polygon-hao (a more robust version of turf/boolean-point-in-polygon)
• sweepline-simplify (replace turf/unkinkPolygon)
• shamos-hoey potentially useful for many of the boolean operations
• continuing to help in a number of libraries related to replacing JSTS (eg writing my own buffer module, helping with some existing union/clip/difference/xor implementations)

Many of the issues and PR's relate to TS definitions on which I have little expertise. The TS user base seem pretty quick to put in issues PR's which is kind of good - as a non-TS user though unfortunately my motivation for learning TS in my spare time and then responding to all those issues & PRs is pretty low so it would be great to have a maintainer who wanted to take on that role.

I do have interest in ongoing involvement in Turf however keeping the project running when I was pretty much the sole person was very hard particularly given the issues I was having with releasing master.

I'm happy to add you as a contributor - TBH though I'm not sure how we move past the stalemate on releasing from master.

Cheers
Rowan

[mfedderly]

@tmcw Thanks for the support! Would you have time to help review PRs as I get up to speed with the codebase?

@rowanwins I'm really glad to hear that you're still interested in working on Turf and that you've built out some more tech towards getting away from turf-jsts. I've actually written a lot of Typescript and managed a few Lerna repos, so it sounds like we have complementary skillsets here.

I think there's a few steps towards getting master releasing again. The first thing I looked into was just getting the repo to build and test locally, I think we could benefit from some package updates here. Additionally, I think its pretty important that the CI system is working well to make sure code that gets merged is of high quality.

The next step after that is probably a conversation about how we want to version with Lerna. We can either have it version every package independently, or have it manage them all with a single version. A single version is simpler, but you wind up with package updates that don't actually have any code changes. Typically the way I've used Lerna to handle releases in the past is to have Lerna write the version numbers into the various package.json files and then make tags which get pushed to Github. Then the CI system takes care of publishing the updates based on the tags. I'm not super familiar with Travis but I'm open to figuring it out. In addition to the versioning, there's a related problem of managing changelogs for each individual package.

Once we've gotten a path towards managing releases, I'm more than happy to work through the Typescript related issues and pull requests (there's a pull request with types for almost every package that I saw yesterday!).

I think if we started by just releasing some smaller incremental updates on v6 that it might give us some momentum to look at making some of the larger changes that people have been interested in doing. We can certainly improve the Typescript consumer's quality of life by just shipping consistent types, and having a coherent versioning scheme.

[stebogit]

Hi all,
I am also interested in contributing again to the library, but same here I don't really know how to approach it. I think I've never dealt with Lerna itself and the build process so I'd need to wait for somebody more competent to make it possible to just be able to push and merge without worry to mess things up. Regardless, I don't think I have admin privileges, at least on npm.

Having said that, I was wondering if you guys are thinking about actually adopting Typescript in Turf, because I remember it was discussed and decided not to here. Did I miss a change of plans?

Anyway, would it be possible to have both JS and TS coexisting in the same library? I mean having the library developed in JS and add sort of a TS "interface" on top of it to allow folks to use that?
In that case we could create a separate "parallel" repo (or just a dedicated folder) for Turf TS based on the original Turf and create the Types definitions in there, which would make easier for TS developers to use the library and contribute to that. That would also allow TS devs to work on the definitions on their own, kida independently from the current structural issues on Turf itself.
Just a thought.

[mfedderly]

@stebogit typically Typescript definitions are either maintained in the library itself or over at DefinitelyTyped. It's easiest for consumers if it is in the library itself. Some of Turf is already written in Typescript, but for packages not written in Typescript you can just publish index.d.ts and point to it from package.json at the typings key.

As for whether Turf itself should be implemented in Typescript, I'd prefer consistency over the current mixed situation, but I don't have an opinion on which way this library should go.

[mfedderly]

Going to close this as I am now a contributor. Looking forward to helping out!

[HarelM]

I haven't found a place describing where this package is headed.
I've read the v7 thread which was very interesting but doesn't seem to be happening, right?
I like TS very much, I think it's super productive.
ES6 and TS 3.7 can generate typings from jsdocs which is great and I'd love to help out with the typings part if needed and agreed that this is the right direction, although it seems @mfedderly is on top of it. :-)
I've seen that 6.2 alpha was released to npm and was wondering what's preventing it from being officially released.
Bottom line, I'd probably love to help out a bit with this library in terms of order and aligning all packages to be the same (I like to do refactoring :-)) but am not sure what are the guide lines currently...

[mfedderly]

@HarelM I haven't released 6.2.0 because of #1866, where we know that some of the results are just wrong.

I think at the moment one typescript project that I'd like to do is to be able to turn on strict mode everywhere. There were a few packages that did not quite meet that bar so when I consolidated the typescript builds I had to turn it off. Another thing that would be helpful is to go through the packages and clean up any types where the javascript implementation differs from the typescript definitions. There was at least one package that could return Feature types that were not listed in the return.

At the moment I think its pretty safe to say that we're looking at correctness and performance work, and trying to avoid breaking changes for a while until things are running more smoothly.

Thanks for the interest in Turf!

[mbullington]

Exciting!

For our products we were using v7 since, as of like a year ago, that seemed like "the way forward" and there are some big changes I'm not sure have been backported yet. We'd like to switch back to mainline @turf/turf but I have the following concerns:

• Biggest among these being v7 uses polygon-clipping, as martinez-polygon-clipping was producing incorrect results that were a non-starter for our usecases.
• Not entirely sure, but I think in our Webpack @turf/turf bundled the browser attribute, which didn't allow for tree shaking. Could this be a solution? https://github.com/webpack/webpack/issues/4674#issuecomment-355853969

Happy to help with these issues on PRs, just wanted to understand maintainer's perspectives first.

[mfedderly]

I published an alpha (6.2.0-alpha.1) that should fix the treeshaking in @turf/turf. Sadly the issues with martinez-polygon-clipping are still there. We're working on getting the upstream library fixed before shipping a consistent 6.x version, tracking that in #1866.

[mbullington]

Thanks for the speedy response, sounds good with the tree shaking.

Are there any issues with the alternative polygon-clipping that make it unsuitable for Turf's needs? We've written tons of unit tests that rely on V7 turf/union and it's been very stable thus far, at least for our uses.

[mfedderly]

If you think you've got it in you, I'd be happy to get a PR that fixes these issues since it helps us unblock the 6.x branch and makes it shippable. I haven't had enough time available yet to tackle that work.