TS 1.6: strict object literal assignment

[jods4]

TS 1.6 introduces more strict type checking on object literals:
microsoft/TypeScript#3823

If an API is commonly meant to be extended, it's good that it adds a generic indexer to its definition for easier consumption.
I think it's the case for RouteConfig.

I had this in my code and it now fails in TS 1.6:

config.map([
  { route: 'test', name: 'test', moduleId: './Views/test', auth: 'admin' },
  // and many more routes like this
]);

The thing to notice is that I use auth to manage authentication and access rights for my routes (which I think is a recommended practice?).
Because auth is not declared in RouteConfig TS raised an error.

There are several ways to remove the error, but in this case I thought that it just made more sense to add [x: string]: any inside the RouteConfig declaration.

The consequence is that we still get intellisense for declared RouteConfig properties, but we may freely extend it with undeclared properties.

[bchavez]

👍 ran into this same issue when using TS 1.6. I also hang off auth and extra parameters in my routes.

[EisenbergEffect]

@bryanrsmith How should we handle that? I don't think that we can do it with Babel, can we?

[bryanrsmith]

@EisenbergEffect Babel does support it. I think we should instead encourage custom data to be added to a property specifically designed for arbitrary data. That would give us more flexibility in internal changes and future API additions. I thought we had such a property documented already, but I'm having trouble finding it now...

[jods4]

Customizing the navigation pipeline in the doc illustrates using auth and friends directly on the route.
http://aurelia.io/docs.html#customizing-the-navigation-pipeline
Maybe the docs should be updated then.

I also note that when you have lots of routes, adding properties on sub-objects it's not very convenient (but doable).

[EisenbergEffect]

@bryanrsmith Yes, there's actually already a property designated for that: settings which is recognized internally by the code. So, we just need to add that to our definitions as an optional property and make sure the settings object type has the type information described above.

[stephenlautier]

That's exactly how I fixed it on mine for the moment.
I added settings?: any; to the RouteConfig interface.

Might be better if it allows generic so we do get type strictness in our custom settings model.