Starting thread for open questions on this PR...

• It was not immediately apparent to me where tests for this change would belong. Would appreciate some pointers!

• Should this change also affect ViteDevServer.transformRequest?
  

  vite/packages/vite/src/node/server/index.ts

  Lines 230 to 237 in 979534e

  	/**
  	* Programmatically resolve, load and transform a URL and get the result
  	* without going through the http request pipeline.
  	*/
  	transformRequest(
  	url: string,
  	options?: TransformOptions,
  	): Promise<TransformResult | null>

  From looking at the implementation of transformRequest, my hunch is "no", but wanted to call this out.

• Would an example of this feature in the playground folder be useful?

• Should this change be back-ported this to 4.x? Or is 4.x feature-frozen as of now? (Happy to back-port if given the go-ahead.)

Tests can go into playground/html with a new plugin that uses this new property perhaps. e.g setting headers. We have a couple tests that tests x-served-by header for example.

transformRequest should not be affected. Those are use for JS mostly.

Yeah this would go into Vite 5. We don't usually backport features to 4.0

Note

originalUrl was added to IndexHtmlTransformContext in 13d41d8, but the docs still reflected the previous type signature. Taking this opportunity to roll in the fix.

Since transformIndexHtml is also called during dev server warmup, when there is no req / res to pass through, is this something which warrants additional documentation or comments?

I think it should be fine undocumented about this case, as long as we document that consumers can optionally pass req or res in dev, e.g. in SSR. So it's not a guarantee.

Wanted to double check something... The type signature of IndexHtmlTransformContext currently permits some invalid values, such as objects with server and bundle. I wonder, why this type not a disjunction?

interface IndexHtmlTransformBuildContext {
  path: string
  filename: string
  // NOTE: `bundle` and `chunk` are optional because they are not set for
  // `transformIndexHtml` with `order: pre`.
  bundle?: OutputBundle
  chunk?: OutputChunk
}

interface IndexHtmlTransformDevContext {
  path: string
  filename: string
  server: ViteDevServer
  originalUrl: string
  // NOTE: `req` and `res` are optional because they are optional in
  // `ViteDevServer.transformIndexHtml`
  req?: Connect.IncomingMessage
  res?: http.ServerResponse
}

export type IndexHtmlTransformDevContext =
  IndexHtmlTransformBuildContext | IndexHtmlTransformDevContext;

Is it because such a change would break types for upstream dependents?

Alternatively, we could keep the existing type signature but group related fields together under commented groups, like:

export interface IndexHtmlTransformContext {
  /**
   * public path when served
   */
  path: string
  /**
   * filename on disk
   */
  filename: string

  // Parameters available during `vite dev` only
  server?: ViteDevServer
  originalUrl?: string
  req?: Connect.IncomingMessage
  res?: http.ServerResponse

  // Parameters available during `vite build only`
  bundle?: OutputBundle
  chunk?: OutputChunk
}

Probably was easier implemented in the past that way 😄 But I think we could change that separately, but yeah I think it would break downstream quite a bit, so maybe not quite worth the change.

Since transformIndexHtml is also called during dev server warmup, when there is no req / res to pass through, is this something which warrants additional documentation or comments?