feat(tilesets): Support widget calculations on tilesets

[donmccurdy]

Changes:

• Migrate local calculations from C4R
• Port local calculations to TypeScript
  • In some cases the types were not obvious, particularly required vs. optional parameters and overloaded types (see: SortColumns). I've used strict TS types where possible, and generally tried to make parameters required for internal functions so that defaults are applied only once at top-level calls.
• Migrate unit tests from C4R
• Add WidgetTilesetSource class
• Refactor WidgetSource class hierarchy:
  • WidgetSource
    • WidgetRemoteSource
      • WidgetTableSource
      • WidgetQuerySource
    • WidgetTilesetSource
• Add tileset example

[padawannn]

Great job @donmccurdy. Some small comments, can you take a look?

[padawannn]

Should we export the ts files instead of js files? I mean

export * from './Filter.ts';

instead of

export * from './Filter.js';

I've notice other exports like this in other places like https://github.com/CartoDB/carto-api-client/blob/main/src/index.ts#L1

[donmccurdy]

We can't do .ts I think, the build process would have to rename the imports in .d.ts files to .js at build time, and TypeScript has for a very long time been against allowing that:

• Feature Request: allow change file extension of generated files from .ts  microsoft/TypeScript#49462

The filenames are supposed to be paths that can be resolved after TypeScript compilation, so we are stuck with either ./Filter or ./Filter.js. Currently the codebase has a mix of both ... so that is not great, I would like to clean it up to be consistent, I'll do that in a new PR. 😅

While I'm happy with either in an app like Builder, I think that for libraries we may need to use .js, because that's what should appear in the published .d.ts files. It's required for customers using certain configurations, particularly moduleResolution: 'nodenext'. I've had this feedback in some of my personal repositories in the past, discussion here:

• Fix type definitions for moduleResolution nodenext donmccurdy/glTF-Transform#827

[donmccurdy]

For now I've opened a new issue to track this:

• Imports should use explicit .js extensions for moduleResolution=nodenext compatibility #99

I'll wait to make the changes until after this PR and the raster PR are merged, so we don't have a bunch of merge conflicts.

[padawannn]

@donmccurdy, why don't we export the file without the extension as Deck.gl does? https://github.com/visgl/deck.gl/blob/master/modules/core/src/index.ts#L90 I mean

export * from './Filter';

[donmccurdy]

So deck.gl is using ... from './Foo' in source files, but they've written a special build step that adds the .js extension to the generated .d.ts files:

https://github.com/uber-web/ocular/blob/6d84ec50d8c80dc2cf361e818e9edb35f597042a/modules/dev-tools/src/ts-plugins/ts-transform-append-extension/index.ts

Added in:

• [dev-tools] ESM module build command improvements uber-web/ocular#446

Admittedly putting the .js extension in source code is weird/ugly... but without customizing the build process I don't know of another way to solve that problem for customers. Another option would be to bundle the .d.ts files into one file, so there are no imports in the output, but that will complicate the build step and I haven't found a build setup that I trust for that yet. 😕

[padawannn]

Thank you for your comments. I've approved the PR but please check this comment #50 (comment)