Version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@spatialdata/core@0.8.0

Minor Changes

• #152 223e066 Thanks @xinaesthete! - Report a failed feature-index scan instead of going quiet.

  getMatchingLoadState returned undefined for a failed matching slot — exactly
  what it returns for "no scan has ever run" — and nothing else exposed the error. So
  a scan that failed looked identical to one that had not started, while the render
  path carried on filtering the resident batch. The panel showed whichever part of the
  selection happened to be inside the memory cap and presented it as the complete
  answer.

  PointsMatchingLoadState gains failed and error, reported for the selection the
  failed scan would have covered (and only that one — a stale failure for a selection
  the user has since changed is not attributed to the new one, and a retained good
  batch no longer masks it). usePointsFeatureState gains retryFailedLoads, and the
  built-in feature filter panel now says the load failed, says the canvas is showing
  only what was already in memory, and offers Retry when the error is retryable.

Patch Changes

• #150 dadcbf8 Thanks @xinaesthete! - Emit the workers and points-worker entries as ES modules.

  The lib fileName named only index per format; every other entry got
  ${entryName}.js from BOTH the es and cjs passes, so the cjs output silently
  overwrote the es one. dist/workers.js and dist/points-worker.js therefore
  shipped as CommonJS under a .js extension inside a "type": "module" package —
  files nothing can load.

  enablePointsWorker constructs the worker with new Worker(url, { type: 'module' }),
  so loading the published points-worker.js failed with ReferenceError: require is not defined and the worker never answered. That made the points worker impossible
  to start outside this repo, and with it the feature-index scan: a points selection
  whose rows fall beyond the memory cap could not be fetched at all, because
  loadPointsMatchingFeatureCodes throws rather than falling back to the main thread.
  The demo did not catch it because it imports the worker's TypeScript source by
  relative path.

  Every entry now names its format, and ./workers gains explicit import/require
  conditions. A packaging test asserts each exports target really is in the module
  system its extension and the package type imply.

@spatialdata/vis@0.8.0

Minor Changes

• #146 9cd27cc Thanks @xinaesthete! - Export the feature-row classification alongside the points feature state.

  usePointsFeatureState returns raw engine signals — residentCodes,
  loadedMatchingCodes, matchingLoadState, supportsOnDemandLoad — and
  describeFeatureRowState is what turns them into a row's rendered state: whether
  it is dimmed, a short label, and a sentence explaining why. Only the former was
  reachable from the package entry, so an embedder building its own feature list had
  the data but not the reading of it, and had to re-derive a precedence order
  (resident/rendered beat selection and scan state) that is easy to get subtly wrong
  — the failure mode being a panel that greys a feature the canvas is drawing.

  Adds describeFeatureRowState and featureRowOpacity, plus the types
  FeatureRowState, FeatureRowStateInput and FeatureRowTone. No behaviour
  change; these already backed the built-in PointsFeatureFilterPanel.

• #152 223e066 Thanks @xinaesthete! - Report a failed feature-index scan instead of going quiet.

  getMatchingLoadState returned undefined for a failed matching slot — exactly
  what it returns for "no scan has ever run" — and nothing else exposed the error. So
  a scan that failed looked identical to one that had not started, while the render
  path carried on filtering the resident batch. The panel showed whichever part of the
  selection happened to be inside the memory cap and presented it as the complete
  answer.

  PointsMatchingLoadState gains failed and error, reported for the selection the
  failed scan would have covered (and only that one — a stale failure for a selection
  the user has since changed is not attributed to the new one, and a retained good
  batch no longer masks it). usePointsFeatureState gains retryFailedLoads, and the
  built-in feature filter panel now says the load failed, says the canvas is showing
  only what was already in memory, and offers Retry when the error is retryable.

Patch Changes

• Updated dependencies [dadcbf8, 223e066]:
  • @spatialdata/core@0.8.0
  • @spatialdata/layers@0.8.0
  • @spatialdata/react@0.8.0
  • @spatialdata/avivatorish@0.8.0

@spatialdata/layers@0.8.0

Patch Changes

• Updated dependencies [dadcbf8, 223e066]:
  • @spatialdata/core@0.8.0

@spatialdata/react@0.8.0

Patch Changes

• Updated dependencies [dadcbf8, 223e066]:
  • @spatialdata/core@0.8.0

@spatialdata/avivatorish@0.8.0