The "paths[1]" argument must be of type string.

codenoid commented 3 months ago

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[x] I have tried the npm run clear or yarn clear command.
[ ] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[ ] I have tried creating a repro with https://new.docusaurus.io.
[ ] I have read the console error message carefully (if applicable).

Description

error while running dev server

user@users-MacBook-Pro docs.lokal.so % npm run start

> docs-lokal-so@0.0.0 start
> docusaurus start

[INFO] Starting the development server...

[ERROR] TypeError [ERR_INVALID_ARG_TYPE]: The "paths[1]" argument must be of type string. Received undefined
    at validateString (node:internal/validators:162:11)
    at Object.resolve (node:path:1101:7)
    at Object.pluginContentBlog [as plugin] (/Users/user/Documents/Business/lokal.so/docs.lokal.so/node_modules/@docusaurus/plugin-content-blog/lib/index.js:51:37)
    at initializePlugin (/Users/user/Documents/Business/lokal.so/docs.lokal.so/node_modules/@docusaurus/core/lib/server/plugins/init.js:83:61)
    at async Promise.all (index 1)
    at async initPlugins (/Users/user/Documents/Business/lokal.so/docs.lokal.so/node_modules/@docusaurus/core/lib/server/plugins/init.js:91:21)
    at async /Users/user/Documents/Business/lokal.so/docs.lokal.so/node_modules/@docusaurus/core/lib/server/plugins/plugins.js:136:36
    at async loadSite (/Users/user/Documents/Business/lokal.so/docs.lokal.so/node_modules/@docusaurus/core/lib/server/site.js:135:45)
    at async createReloadableSite (/Users/user/Documents/Business/lokal.so/docs.lokal.so/node_modules/@docusaurus/core/lib/commands/start/utils.js:50:16)
    at async Command.start (/Users/user/Documents/Business/lokal.so/docs.lokal.so/node_modules/@docusaurus/core/lib/commands/start/start.js:22:28) {
  code: 'ERR_INVALID_ARG_TYPE'
}

Reproducible demo

No response

Steps to reproduce

install @latest docusaurus on 5 June 2024 (GMT+7)
init docusaurus project with javascript
run npm run start

Expected behavior

dev server running

Actual behavior

erroring

TypeError [ERR_INVALID_ARG_TYPE]: The "paths[1]" argument must be of type string. Received undefined

Your environment

Public source code:
Public site URL:
Docusaurus version used: 3.4.0
Environment name and version (e.g. Chrome 89, Node.js 16.4):
Operating system and version (e.g. Ubuntu 20.04.2 LTS): Macbook Pro M1 Max

Self-service

[ ] I'd be willing to fix this bug myself.

lominming commented 3 months ago

Also hitting this error today

mempoule commented 3 months ago

Same problem here :

[ERROR] Error: Unable to build website for locale fr. [cause]: TypeError [ERR_INVALID_ARG_TYPE]: The "paths[1]" argument must be of type string. Received undefined

mempoule commented 3 months ago

tried using typescript, with no success, it seems even when forcing the use of 3.3.2, 3.3.0 or even 3.2 I got the same error.

Would that be a dependency problem ?

rossbulat commented 3 months ago

I am getting the same error upon installing a fresh install and for current projects.

[ERROR] TypeError [ERR_INVALID_ARG_TYPE]: The "paths[1]" argument must be of type string. Received undefined
    at validateString (node:internal/validators:162:11)
    at Object.resolve (node:path:1101:7)

decaf-dev commented 3 months ago

I am getting this error as well. I just created a fresh project using bunx

bunx create-docusaurus@latest my-website classic --typescript
bun run start

I'm also getting it with older versions

bunx create-docusaurus@3.1 my-website classic --typescript
bun run start

sapshah commented 3 months ago

Getting the same error as well

denestamko commented 3 months ago

Same issue for us as well: https://github.com/innomotics/brand-experience/actions/runs/9378506713/job/25821930424

Had no issues 2 days ago.

Merpyzf commented 3 months ago

Getting the same error as well.

Vincent-Tam commented 3 months ago

I'm getting same issue when I npm run start either on my current project or a fresh project. Had no issues a day ago.

Docusaurus version used: 3.3.2/3.4.0

Node version:18.17.0


[INFO] Starting the development server...

[ERROR] TypeError [ERR_INVALID_ARG_TYPE]: The "paths[1]" argument must be of type string. Received undefined at new NodeError (node:internal/errors:405:5) at validateString (node:internal/validators:162:11) at Object.resolve (node:path:1097:7) at Object.pluginContentBlog [as plugin] (/Users/266/Documents/github/docusaurus_test/node_modules/@docusaurus/plugin-content-blog/lib/index.js:51:37)

shochdoerfer commented 3 months ago

Same problem this morning ;(

webprofusion-chrisc commented 3 months ago

yarn build was working for me, I pushed to github for release and the build action failed, this suggests there is a dependency that's not pinned to a version so it was ok locally and not ok when built fresh. When I then cleared my local node modules and package locks etc it also fails.

The error occurs specifically in pluginContentBlog, but this may just be the first plugin the build tries to load - I don't use the blog plugin but I do use preset-classic.

Here is an example commit triggering the error (and repo that exhibits the problem): https://github.com/webprofusion/certify-docs/commit/2d7696f6cfbdf4213d8b7915d27459074e732c5a#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519

[ Edit 1] The actual line that hits a problem is indeed specific to the blog plugin:

https://github.com/facebook/docusaurus/blob/main/packages/docusaurus-plugin-content-blog/src/index.ts#L104

It's trying to find options.path which is undefined (options exists and has an id 'default' but there is no path property)

[Edit 2] My config only uses blogs in docusaurus.config.js and adding false config does let it skip past the unused plugin but eventually it hits a property that's undefined elsewhere in the next plugin (in my case additionalLanguages of the themeClassic plugin). I'm guessing something usually populates the default options for each plugin and that's not happening.

        pages: false,
        blog: false,
        docs: {
            path: './docs',
            sidebarPath: require.resolve('./sidebars.js')
        },
       ...
}

For those interested, note that you can debug this stuff in vscode by hovering over the build script line in package.json then choose Debug Script. then you can hit breakpoints etc.

janmyszkier commented 3 months ago

adding

          authorsMapPath: '',

to blog config section solves part of the problem with docusaurus write-translations that casues this, but I'm digging further

EaveLuo commented 3 months ago

It broke my heart! This is my first time using it, but this project doesn't work and I can't even start it.

slorber commented 3 months ago

This is a non-retro compatible update in Jiti v1.21.1, the tool we use to load plugin module graphs.

https://github.com/unjs/jiti/issues/237

Reverting to Jiti v1.21.0 fixes the problem.

Make sure you don't have the problematic version of Jiti in your lock file.

yarn users can use the following:

  "resolutions": {
    "jiti": "1.21.0"
  },

I'd encourage you to downgrade Jiti rather than try to find another workaround because other things might be broken as well.

Note: if you don't have a lockfile, you should really have one to prevent such issues from randomly appearing in your project. This kind of problem should only happen when you upgrade site dependencies.

FredericEspiau commented 3 months ago

Hey this is the issue: https://github.com/unjs/jiti/releases/tag/v1.21.1

I guess there were some breaking changes

edit: damn, 8 minutes too late

@slorber you don't provide a lock file, thus the dependencies will be resolved according to your package's package.json file, where the version for jiti is ^

homotechsual commented 3 months ago

This is a non-retro compatible update in Jiti v1.21.1, the tool we use to load plugin module graphs.

unjs/jiti#237

Reverting to Jiti v1.21.0 fixes the problem.

Make sure you don't have the problematic version of Jiti in your lock file.

yarn users can use the following:
  "resolutions": {
    "jiti": "1.21.0"
  },
I'd encourage you to downgrade Jiti rather than try to find another workaround because other things might be broken as well.

Note: if you don't have a lockfile, you should really have one to prevent such issues from randomly appearing in your project. This kind of problem should only happen when you upgrade site dependencies.

The template doesn't have a lock file so any new site is getting the incompatible version. We probably need to adjust the version constraint for this?

homotechsual commented 3 months ago

For npm users you can simply add the constraint in your own package.json file directly as "jiti": "1.21.0". Yarn users should use the resolutions fix advised by @slorber

pi0 commented 3 months ago

Hi all. jiti@1.21.2 was released as a hotfix for this issue. You can remove the resolution and upgrade your lock file to receive the fix 🤞🏼

homotechsual commented 3 months ago

Confirming - I no longer see the issue on fresh installs or existing installs without the constraint or explicit dependency.

slorber commented 3 months ago

Thanks @pi0 !

facebook / docusaurus