Skip to content

Conversation

@timnyborg
Copy link
Contributor

@timnyborg timnyborg commented Nov 26, 2025

Cleans up imports of geojson types, so all files import from geojson directly.

Removes export of standard geojson types from the library. This will require anyone doing an import { FeatureCollection, ... } from '@deck.gl-community/editable-layers' to follow suit.

@timnyborg timnyborg force-pushed the remove-geojson-reexports branch from c16a9fc to 86a208b Compare November 26, 2025 21:12
Copy link
Collaborator

@ibgreen ibgreen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appreciate the intent here.

I do have some concerns, putting on the hat of the vis.gl TSC (Technical Steering Committee) so to speak:

  • We are making a minor release, and removing these exports would break apps.
    • I am not sure what percentage of users would be affected
    • But this is the most downloaded module in deck.gl-community, so it will likely cause some upgrade pains.
  • Since the cycle between major releases is quite long, we do occasionally make small breaking changes in the API when we feel it is justified / no good alternative.
  • But in this case it is more of a cleanup than a necessary change.
  • While the work required to upgrade is small, we don't want to underestimate the inconvenience for users.

An alternative is that we move these definitions to the end of the index.ts and mark them as deprecated, and will be removed in next major release.

  • We could also add the @deprecated keyword so that vscode strikes over the symbols.

index.ts:

// DEPRECATED EXPORTS - Will be removed in v10
import type {Point as GeoJsonPoint, ...} from 'geojson';

/** @deprecated Will be removed, import directly from 'geojson' module */
export type Point= GeoJsonPoint;

@ibgreen
Copy link
Collaborator

ibgreen commented Nov 28, 2025

Apart from the breaking change concern, I am just providing some perspective in case it could be helpful:

As we go down the track of reviewing the types in editable-layers, I think it could be worthwhile to discuss whether we keep the geojson dependency at all...

  • As a principle. in vis.gl we want our libraries to have as few dependencies as possible.
  • One characteristic of TypeScript is that types are compatible if they are structurally equivalent
  • This means that we don't necessarily need to import another library here, we could just define any types we need in geojson-types.ts.
  • We'd just make sure that editable-layers would still be compatible with GeoJSON types the user might define, whether from geojson or other sources.

Overall, I feel that our focus should be on making the editable-layers API fully typed.

  • My hunch is that giving the typing of the properties field more attention might be worthwhile.
  • I have rarely had problems with the non-properties GeoJSON types.

Another thing we might possibly want to offer is a small zod schema for geojson types to help validate that input actually matches the types.

  • One option could be to create a small @math.gl/geojson module with such features, then we'd keep this all within the vis.gl ecosystem and we could reuse such types in the deck.gl geojson layer etc.

@ibgreen
Copy link
Collaborator

ibgreen commented Dec 2, 2025

@timnyborg Any thoughts, maybe if you can articulate why you suggested this change we can get to a consensus?

@timnyborg
Copy link
Contributor Author

timnyborg commented Dec 6, 2025

@timnyborg Any thoughts, maybe if you can articulate why you suggested this change we can get to a consensus?

Honestly, just to clean up imports & exports that were made redundant by my turf 7 upgrade. Turf vs nebula vs geojson type differences gave me no end of trouble over the years, so I see value in settling on the dominant library (geojson) and not reinventing the wheel. That said, I probably won't be using these libraries again for the foreseeable 😢. I've been ensuring all the fixes I submitted to nebula.gl over the years make it in, and they finally have, so I'm not bothered either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants