feat: add support for 3rd party resolver

[Jordan-Hall]

This PR closes Custom Resolvers #156.

Created this so someone can create an Angular resolver now we have Angular working with vite

[hannoeru]

This will not works, because it will resolved to the same virtual id.
For multiple instance, we need different virtual id.

[Jordan-Hall]

I was thinking you can just use different ones for the plugin:

Pages({
      // load some vue files
    }),
    Pages({
      react: true,
     moduleId: '~react-pages-billing'
    }),
    Pages({
      react: true,
     moduleId: '~react-pages-crm'
    }),

[hannoeru]

I think we need some new interface for resolver, because you still need to handle the other parts like stringify dynamic import for different frameworks.

[Jordan-Hall]

I think we need some new interface for resolver, because you still need to handle the other parts like stringify dynamic import for different frameworks.

Looking at the work from Angular. It seems to work ok, However, I do agree a new interface would be better as I notice Vue is different from the others.

I'll work on the new interface and update

[Jordan-Hall]

@hannoeru

I was thinking Maybe the resolver doesn't need a different interface it makes sense as a simple resolver. My thinking is to add a Page controller (taken from page context)

In this regard people can extend from the current PageContext and override the current functionality. This way people don't have to implement everything unless it's required.

Option 1:

export interface IPageControl {
  setLogger(logger: Logger): void
  setUserOptions(userOptions: UserOptions): void
  setViteInfo(viteRoot: string): void

  addPage(path: string | string[], pageDir: PageOptions): void | Promise<void>
  removePage(path: string | string[]): void
  checkCustomBlockChange(path: string): void | Promise<void>
  resolveRoutes(): Promise<string>
  onUpdate?(): void
  customBlockMap: Map<string, CustomBlock>
  pageRouteMap: Map<string, PageRoute>
  debug: Record<string, Debug.Debugger>
}

export interface ResolverConstructor {
  // eslint-disable-next-line @typescript-eslint/no-misused-new
  new(userOptions: UserOptions, viteRoot: string): Resolver
}
export interface Resolver {
  setLogger(logger: Logger): void
  setUserOptions(userOptions: UserOptions): void
  setViteInfo(viteRoot: string): void
  resolveRoutes(ctx: IPageControl): Promise<string>
}

Option 2: make the Resolver class have the IPageController

export interface ResolverConstructor {
  // eslint-disable-next-line @typescript-eslint/no-misused-new
  new(userOptions: UserOptions, viteRoot: string): Resolver
}
export interface Resolver {
  setLogger(logger: Logger): void
  setUserOptions(userOptions: UserOptions): void
  setViteInfo(viteRoot: string): void
  resolveRoutes(): Promise<string>

  addPage(path: string | string[], pageDir: PageOptions): void | Promise<void>
  removePage(path: string | string[]): void
  checkCustomBlockChange(path: string): void | Promise<void>
  onUpdate?(): void
  customBlockMap: Map<string, CustomBlock>
  pageRouteMap: Map<string, PageRoute>
  debug: Record<string, Debug.Debugger>
}

In option two, I'll create a base class which is an abstraction of PageContext. We remove the functions intro another class which then allows people to extend the original class and overwrite the functionality

[Jordan-Hall]

@hannoeru I've made Page Context changeable. I'm not sure if this should just be the Resolver or to allow the two to be set independently

[hannoeru]

Thanks for this PR but I think this is too complex, we can just change resolver's interface to add more hooks like rollup's plugin, that we can use the same resolver interface for internal resolver and 3rd party resolver, don't need to change entire page context structure.

interface PageResolver {
  resolvePages()
  onClientGenerate()
  onPageAdded()
  onPageRemoved()
  onPageChanged()
  stringifyComponent()
}