Definitelytyped: Leaflet: TileLayerOptions interface has a [name: string]: any in it

[estaub]

The TileLayerOptions interface includes
[name: string]: any as a member, which makes the interface largely uncheckable.

I suspect this may have been a stopgap while some missing properties were backlogged. If it's not needed, it would be great to kill it.

[atd-schubert]

@alejo90 I think you added this line. Do you still know why? I would also "kill" this line...

[alejo90]

I don't remember anymore. I agree, let's remove it.

[flumpt]

I am using Leaflet.EdgeBuffer which introduces a new member edgeBufferTiles.

After this change the compiler obviously throws an error:
Object literal may only specify known properties, and 'edgeBufferTiles' does not exist in type 'TileLayerOptions'.

Do you know a better solution than just to @ts-ignore the member?

Thanks in advance!

[atd-schubert]

I think the best way would be a Type Definition for this library that enhances the options. I can take a look at that this weekend...

[oleksmarkh]

@alejo90, any chance that the reason for that wildcard was something like an ability to pass additional URL params? For instance, having urlTemplate like https://api.tiles.mapbox.com/v4/{id}/{z}/{x}/{y}.png?access_token={accessToken} these params are id and accessToken.

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/30176 makes the following impossible:

import * as L from 'leaflet';

...

const tileLayer = L.tileLayer(
  urlTemplate,
  {
    ...{allowedProperties}, // anything from "TileLayerOptions"
    id: 'mapbox.light',
    accessToken: '<some-token>',
  }
);

[nelsonghezzi]

Hi!

I agree with @oleksmarkh on the intent of the wildcard property.

In my case, I'm using cql_filter (a GeoServer vendor-specific parameter).

In fact, I think removing the [name: string]: any part makes the interface non-conforming with the Leaflet docs for TileLayer.WMS options, which states:

If any custom options not documented here are used, they will be sent to the WMS server as extra parameters in each request URL. This can be useful for non-standard vendor WMS parameters.

In my interpretation, that's saying additional parameters are valid and would be sent as-is to the WMS server.

[alejo90]

@oleksmarkh @nelsonghezzi I honestly don't remember but what you're saying sounds right to me. If @atd-schubert has no objection, we can put it back.

[atd-schubert]

I think it the current way is much type-safer then the other one. For example:

let layer = tileLayer("", { maxNaiveZoom: 1 });

This is potentially a typo and would not be correct in the current definition, but is valid in the other.

As long as you just want to tell your compiler it shall treat it like type TileLayerOptions (and "omit" additional properties for the static tests), you just have to write in the current version:

let layer = tileLayer("", { maxNaiveZoom: 1 } as TileLayerOptions);

Now the developer must / can specify that additional properties are expected.