Msw: TypeScript 4.1 and template literal types to infer Request Params

[timdeschryver]

Is your feature request related to a problem? Please describe.

Coming from https://github.com/mswjs/msw/pull/421
We could try to infer the request params from the URL by using template literal types (introduced in TS 4.1).
See this example(not mine).

Describe the solution you'd like

I think this can be done within 2 steps

• [ ] Update to TS 4.1
• [ ] Try to use template literal types, because I'm not 100% sure if it works within this situation

Describe alternatives you've considered

The current solution is to provide a generic for the params.

Additional context

/

[kettanaito]

Hey, @timdeschryver. Thank you for suggesting this. I think path parameters matching in this way would be much more versatile and seamless for the developer. I wonder how TS works when that path string is dynamically constructed?

It looks like bumping to typescript: 4.1.x wouldn't even be a breaking change, as we rely on 4.0.x at the moment. That being said, how should we handle such TypeScript updates for the consumers of the library? Should we specify a TypeScript version in the peerDependencies?

[timdeschryver]

That's a good question.

I'm not familiar with the template expression but I think dynamically constructed won't get inferred automatically. The developer will have to provide the generic manually, as she has to do today.

About the TypeScript version, we'll have to try it first. I do think it would be breaking because it's a new feature, it could be that the type will be any or unknown in earlier version but again, I'm not sure about it.

Sorry if I can't provide answers on this one (yet).
I'll try to play with it later, as soon as v4.1 is released (it's currently in beta).

[tigerabrodi]

@kettanaito You had a label here "help wanted"?

Is there anything I could do from my side in this particular issue?

[timdeschryver]

I didn't do anything for this, but now that TS 4.1 is released this issue can be implemented now.
Once it is, we can decide if it actually improves the DX.

If you want to take this @tigerabrodi , feel free to do so from my end.

[tigerabrodi]

@timdeschryver This looks pretty complex :sweat_smile:, I'd be down to review the PR or assist on this one though :100:

[tigerabrodi]

Even if I was to implement it, may I ask where in the code? Also the current solution uses a generic right?

[timdeschryver]

To be honest, I'm not sure either about the where and the how 😅
I can try something and ping you for a review if you'd like.

[tigerabrodi]

@timdeschryver Yeah for sure! I would also checkout the PR locally :tada:

Something I forgot to ask though, how will this "inferring" be better than using generics? I have not read about it, but am really curious :smiley:

[timdeschryver]

You wouldn't need to add a generic manually, it would just work 🧙‍♂️

[tigerabrodi]

@timdeschryver Ahhh lit :metal: TypeScript ain't playing this time :smile: :joy:

As mentioned, I can review the PR, would also checkout the changes locally :tada: :raised_hands:

[timdeschryver]

Fyi, I'm working on this in infer-req-params.
Sadly, from the looks of it, this change brings a breaking change with it, and we might lose the possibility to type the request body and response (perhaps this is a good thing? see https://effectivetypescript.com/2020/08/12/generics-golden-rule/).
Will take a second look at it during the week to see if we could resolve this.

[timdeschryver]

After giving this some thought, I don't think it will work with the existing generics.
I mean, it will be it won't look pretty, you would have to provide the URL as a generic...

rest.get<any, ResponseType, 'https://api.github.com/users/:username/messages/:messageId'>(
  rest.get('https://api.github.com/users/:username/messages/:messageId', () => ....)

I also tried to support both but this would require a lot of types and I don't know if it's worth it, and if it's even possible in the end.

How do we want to proceed with this, because at first I didn't think that it would be this "destructive".