This won't work if the async result isn't serializable by Structured Clone Algorithm

[JounQin]

Structured Clone Algorithm

For example, plugins in resolveConfig.

[fisker]

That's limitation, maybe we should mention that.

[SimenB]

This blocks Jest from using the package as well - we have a custom parser: https://github.com/jestjs/jest/blob/e9125e3f4676fb6a7e926042b39f1dfd5c51ec4b/packages/jest-snapshot/src/InlineSnapshots.ts#L332-L400

[JounQin]

I believe this can be done with custom worker without depending on @prettier/sync like we do in eslint-plugin-prettier

What means doing all heavy jobs in the worker, and only return the result from it to bypass the limitations.

@SimenB

[fisker]

Can this extract to a separate file and pass location as prettier plugin?

[remcohaszing]

Prettier plugins can be specified using a path, but this puts a limitation on end users.

I suggest to add a function like this:

/**
 * Format content with the Prettier context for the file path.
 *
 * If the file is ignored by Prettier, the content is returned as-is.
 *
 * @param {string} filepath
 *   The file path to resolve the configuration for.
 * @param {string} content
 *   The content to format.
 * @param {import('prettier').Options} [options]
 *   Additional Prettier options to apply.
 * @returns {string}
 *   The formatted content, or the content as-is if it’s ignored by Prettier.
 */
async function formatWithContext(filepath, content, options) {
  const fileInfo = await getFileInfo(filepath)

  if (fileInfo.ignored) {
    return content
  }

  if (!fileInfo.inferredParser) {
    return content
  }

  const config = await resolveConfig(filepath, { editorconfig: true })

  return format(content, { ...config, ...options, filepath })
}

This means there is no need to send the Prettier options between workers. I imagine this would even be useful to add to Prettier itself, as I think it’s a common use case to format files like that.