Rolling back cloning workaround from commit d7c5322. This appears to have been unnecessary, possibly already having been fixed by adding linearRing: false to the isoContours call.

Author: smallsaucepan

packages/turf-isolines/index.ts

@@ -1,5 +1,4 @@
 import bbox from "@turf/bbox";
-import clone from "@turf/clone";
 import { coordEach } from "@turf/meta";
 import { collectionOf } from "@turf/invariant";
 import { multiLineString, featureCollection, isObject } from "@turf/helpers";
@@ -157,35 +156,11 @@ function rescaleIsolines(
     point[1] = point[1] * scaleY + y0;
   };
 
-  // Ok. We need to *clone* the returned isolines due to the behaviour of
-  // the marchingsquare library behaviour. Long story short, if we don't
-  // do this, the last point in some isoLines has the coordEach function
-  // run twice, leading to one point in the isoline rendering WAY out of
-  // position.
-  const clonedIsoLines: Feature<MultiLineString>[] = [];
-  createdIsoLines.forEach((isoline) => {
-    clonedIsoLines.push(clone(isoline));
-  });
-
   // resize and shift each point/line of the createdIsoLines
-  clonedIsoLines.forEach((isoline) => {
+  createdIsoLines.forEach((isoline) => {
     coordEach(isoline, resize);
   });
-  return clonedIsoLines;
+  return createdIsoLines;
 }
 
-/*
- * A bit more background on the isoContours behaviour described above. It
- * seems like in some cases the last coord of the line references the same
- * coord array as the first point. This just seems to be the way they're
- * returned from the library:
- * [0] -> A
- * [1] -> B
- * [2] -> C
- * [3] -> A
- * Running coordEach over this mutates the values in A, then B and C, then
- * mutates [3] which happens to also be a reference to A. So the rescale
- * transform is run twice on that coord.
- */
-
 export default isolines;