Inject Dynamic url parameter into template

Describe the bug A clear and concise description of what the bug is. What i’m seeing is that with next v11 the following code works in a way where the id url parameter is injected into the template name:

  @Get('/:id')
  @Render('[id]') // if :id were '2' the template name would be [2]
 public post(@Param('id') id: string) {
    return {id};
  }

However with next v12 this doesn’t seem to work anymore. What i’ve observed with v12 is that ctx.query.id is set to the string [id] rather than the actual id value.

Expected behavior A clear and concise description of what you expected to happen.

I’d expect the behavior with next v11 to be the same as v12. I’m not sure if nest-next module should be bridging the gap but it would be neat for this to still work as it did.

To Reproduce

Repository URL:

Version

• next.js: 12.1.1
• nest: 8.0.0
• nest-next: 9.6.0

Additional context Add any other context about the problem here.

[rushil-patel]

@kyle-mccarthy Yeah sure thing. Here is a demo repo. The master branch is working as expected with Next v11. I put a branch called next-12 where you can observe the broken behavior, following these steps: repo: https://github.com/rushil-patel/nest-next-test

// SETUP Clone nest-next-test repository and check out the next-12 branch

• yarn

• yarn build

• yarn start

• Navigate to http://localhost:3000/1 // you’ll see a 500 internal error

You’ll see in the stacktrace that the id url parameter is not 1 but ends up being [id].

To see it work with next 11 checkout the master branch and run the exact 4 steps above

[kyle-mccarthy]

Hey, sorry, I just had the opportunity to look into this issue. I noticed that in your example, you used the monorepo approach; this was contributed by a member that has since deleted their GitHub account. Unfortunately, this was never a use case of mine, and I cannot provide any meaningful suggestions or workarounds.

That being said, the “basic” example still works as expected. The primary difference between the “basic” and “monorepo” example is that the monorepo attempts to bypass how Next treats the pages directory. Next is pretty opinionated in how they treat the pages directory, even when using the custom server approach.

It may be possible to get around the problem by symlinking the pages directory; however, this is obviously less than ideal. Given that the contributor can no longer provide support, I will start to remove the example and references to it in the documentation.

If you can get it working, I would appreciate it if you could let me know or make a PR with fixes for the documentation and examples.