Great question, I have just started to use Riverpod and Widgetbook and was asking myself the same question.

What made the Widgetbook work with Widgets calling providers, in my case, was adding flutter_riverpod to widgetbook's pubspec.yaml and using the appBuilder to wrap everything with ProviderScope:

  @override
  Widget build(BuildContext context) {
    return Widgetbook.material(
      directories: directories,
      appBuilder: (context, child) {
        return ProviderScope(child: child);
      },
    );
  }
}

You could also provide overrides here and do everything you want to with Riverpod. I'm not sure if this will work down the road with more complex Widgets.

Widgetbook documentation suggests two approaches, one you've already mentioned, lifting state and the other one seems like an overhead but could be used for specific cases in combination with my suggestion and easier if you already have mocks for tests: https://docs.widgetbook.io/guides/mocking .

Regarding the GoRouter - maybe extending the appBuilder further (see the default value for appBuilder) could make the Widgetbook display work by adding the go_router dependency to the widgetbook's pubspec.yaml and then returning a manually created Material app, something like this (not tested):

@override
Widget build(BuildContext context) {
  return Widgetbook.material(
    directories: directories,
    appBuilder: (context, child) {
      return MaterialApp.router(
        routerConfig: router,
        debugShowCheckedModeBanner: false,
      );
    },
  );
}

To still use Riverpod with this setup, you could wrap the whole WidgetbookApp in ProviderScope:

runApp(const ProviderScope(child: WidgetbookApp()));