ERR_UNSUPPORTED_ESM_URL_SCHEME error on build

[daalgi]

Describe the bug
The site runs ok locally npm run dev, but raise errors when npm run build.

PS D:\DEV\demo\tailwind-nextjs-starter-blog> npm run build

> tailwind-nextjs-starter-blog@2.0.1 build
> cross-env INIT_CWD=$PWD next build && cross-env NODE_OPTIONS='--experimental-json-modules' node ./scripts/postbuild.mjs

Warning: Contentlayer might not work as expected on Windows
successCallback D:/DEV/demo/tailwind-nextjs-starter-blog/.contentlayer
SuccessCallbackError {
  error: Error: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'd:'
      at new NodeError (node:internal/errors:405:5)
      at throwIfUnsupportedURLScheme (node:internal/modules/esm/load:131:11)
      at defaultLoad (node:internal/modules/esm/load:82:3)
      at nextLoad (node:internal/modules/esm/loader:163:28)
      at ESMLoader.load (node:internal/modules/esm/loader:603:26)
      at ESMLoader.moduleProvider (node:internal/modules/esm/loader:457:22)
      at new ModuleJob (node:internal/modules/esm/module_job:64:26)
      at ESMLoader.#createModuleJob (node:internal/modules/esm/loader:480:17)
      at ESMLoader.getModuleJob (node:internal/modules/esm/loader:434:34) {
    code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME'
  },
  _tag: 'SuccessCallbackError',
  toString: [Function (anonymous)],
  [Symbol()]: {
    error: Error: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'd:'
        at new NodeError (node:internal/errors:405:5)
        at throwIfUnsupportedURLScheme (node:internal/modules/esm/load:131:11)
        at defaultLoad (node:internal/modules/esm/load:82:3)
        at nextLoad (node:internal/modules/esm/loader:163:28)
        at ESMLoader.load (node:internal/modules/esm/loader:603:26)
        at ESMLoader.moduleProvider (node:internal/modules/esm/loader:457:22)
        at new ModuleJob (node:internal/modules/esm/module_job:64:26)
        at ESMLoader.#createModuleJob (node:internal/modules/esm/loader:480:17)
        at ESMLoader.getModuleJob (node:internal/modules/esm/loader:434:34) {
      code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME'
    }
  },
  [Symbol()]: [ 'error' ]
}
- info Creating an optimized production build .

To Reproduce
Steps to reproduce the behavior:

npx degit 'timlrx/tailwind-nextjs-starter-blog'
npm i
npm run build

Expected behavior
Build without errors.

System Info (if dev / build issue):

• OS: Windows 10 Pro
• Node version: 18.17.1
• Npm version: 9.8.1

[anggara-26]

Same hereee

[timlrx]

Yes, there seems to be an error on the onSuccess callback hook in Contentlayer when running on windows: contentlayerdev/contentlayer#477

As a workaround, I suggest commenting out the onSuccess hook and doing the transformation during the transformation manually:

Add the following script to ./scripts/postContentlayer.mjs:

import { writeFileSync } from 'fs'
import GithubSlugger from 'github-slugger'
import { allCoreContent, sortPosts } from 'pliny/utils/contentlayer.js'
import { allBlogs } from '../.contentlayer/generated/index.mjs'
import siteMetadata from '../data/siteMetadata.js'

const isProduction = process.env.NODE_ENV === 'production'

/**
 * Count the occurrences of all tags across blog posts and write to json file
 */
export async function createTagCount() {
  const tagCount = {}
  allBlogs.forEach((file) => {
    if (file.tags && (!isProduction || file.draft !== true)) {
      file.tags.forEach((tag) => {
        const formattedTag = GithubSlugger.slug(tag)
        if (formattedTag in tagCount) {
          tagCount[formattedTag] += 1
        } else {
          tagCount[formattedTag] = 1
        }
      })
    }
  })
  writeFileSync('./app/tag-data.json', JSON.stringify(tagCount))
}

export async function createSearchIndex() {
  if (
    siteMetadata?.search?.provider === 'kbar' &&
    siteMetadata.search.kbarConfig.searchDocumentsPath
  ) {
    writeFileSync(
      `public/${siteMetadata.search.kbarConfig.searchDocumentsPath}`,
      JSON.stringify(allCoreContent(sortPosts(allBlogs)))
    )
    console.log('Local search index generated...')
  }
}

async function postContentlayer() {
  await createTagCount()
  await createSearchIndex()
}

postContentlayer()

You can then run node ./scripts/postContentlayer.mjs before running yarn dev again. It's not the perfect solution - ideally the issue is patched on contentlayer side or there' a next config plugin to manipulate the assets before next server is run, but this would at least enable you to run the template on windows.

[aolyang]

I made a PR contentlayerdev/contentlayer#571 to fix this.

before new version of contentlayer or @contentlayer/core released, you can manually compile or create a patch update:

https://yarnpkg.com/cli/patch

https://pnpm.io/cli/patch

make a chagne in @contentlayer/core/dist/generation/generate-dotpkg.js , do a temp fix.

+import * as URL from "url"

 const successCallback = (onSuccess) => {
     if (!onSuccess)
         return T.unit;
-    return pipe(getCwd, T.map((cwd) => ArtifactsDir.getDirPath({ cwd })), T.tapSync((path) => console.log('successCallback', path)), T.chain((generatedPkgPath) => T.tryCatchPromise(() => onSuccess(() => import(filePathJoin(generatedPkgPath, 'generated', 'index.mjs'))), (error) => new SuccessCallbackError({ error }))), OT.withSpan('@contentlayer/core/generation:successCallback'));
+    return pipe(getCwd, T.map((cwd) => ArtifactsDir.getDirPath({ cwd })), T.tapSync((path) => console.log('successCallback', path)),
+        T.chain((generatedPkgPath) => T.tryCatchPromise(() => onSuccess(() => import(
+            URL.pathToFileURL(
+                filePathJoin(generatedPkgPath, 'generated', 'index.mjs')))
+            )
+        ,
+        (error) => new SuccessCallbackError({ error }))), OT.withSpan('@contentlayer/core/generation:successCallback'));
 };

[athrael-soju]

Yes, there seems to be an error on the onSuccess callback hook in Contentlayer when running on windows: contentlayerdev/contentlayer#477

As a workaround, I suggest commenting out the onSuccess hook and doing the transformation during the transformation manually:

Add the following script to ./scripts/postContentlayer.mjs:

import { writeFileSync } from 'fs'
import GithubSlugger from 'github-slugger'
import { allCoreContent, sortPosts } from 'pliny/utils/contentlayer.js'
import { allBlogs } from '../.contentlayer/generated/index.mjs'
import siteMetadata from '../data/siteMetadata.js'

const isProduction = process.env.NODE_ENV === 'production'

/**
 * Count the occurrences of all tags across blog posts and write to json file
 */
export async function createTagCount() {
  const tagCount = {}
  allBlogs.forEach((file) => {
    if (file.tags && (!isProduction || file.draft !== true)) {
      file.tags.forEach((tag) => {
        const formattedTag = GithubSlugger.slug(tag)
        if (formattedTag in tagCount) {
          tagCount[formattedTag] += 1
        } else {
          tagCount[formattedTag] = 1
        }
      })
    }
  })
  writeFileSync('./app/tag-data.json', JSON.stringify(tagCount))
}

export async function createSearchIndex() {
  if (
    siteMetadata?.search?.provider === 'kbar' &&
    siteMetadata.search.kbarConfig.searchDocumentsPath
  ) {
    writeFileSync(
      `public/${siteMetadata.search.kbarConfig.searchDocumentsPath}`,
      JSON.stringify(allCoreContent(sortPosts(allBlogs)))
    )
    console.log('Local search index generated...')
  }
}

async function postContentlayer() {
  await createTagCount()
  await createSearchIndex()
}

postContentlayer()

You can then run node ./scripts/postContentlayer.mjs before running yarn dev again. It's not the perfect solution - ideally the issue is patched on contentlayer side or there' a next config plugin to manipulate the assets before next server is run, but this would at least enable you to run the template on windows.

Nice workaround, thanks