Error: Cannot find module 'is-odd' about help HOT 27 CLOSED

Hi! This repo is issues with the NodeJS core, and this looks like an issue with a package installation.

But, to answer your question, modules are usually installed with npm install <module> (or similar, depending on your package manager).
Installed packages typically appear in ./node_modules/<module>, so if that folder doesn't exist, than the package is not installed.

If your experiencing an issue with pnpm, please file an issue in their repository.

Thank you!

from help.

Hi! If you delete the package-lock and pnpm-lock files and run npm i, then test the code in the latest version (v20.1.3 for LTS), will this issue still occur?

Yes, it is working when I use npm
I mean there is no issues when using npm

from help.

Well, the change from Node.js v18 to Node.js v20 was breaking, as with major release lines, so breakages are expected, maybe the pnpm team knows?

from help.

I am not familiar with the underlying mechanisms of node and pnpm, but I found some very strange nodejs behaviors when reproducing this problem.

 node --version
v22.4.1

const fs = require('fs')
const { createServer } = require('net')
const mySocketFile = '/tmp/mysocketfile';

if (fs.statSync(mySocketFile, { throwIfNoEntry: false }))
  fs.unlinkSync(mySocketFile);

// magic line
createServer((socket) => { }).listen(mySocketFile);

setTimeout(async () => {
  try {
    console.log('resolve: ', require.resolve('is-even'))
    require('is-even')
  } catch (e) {
    console.log("err:", e)
  }
});

Run the above code multiple times. If an error occurs, the output should be a file path similar to the following:

resolve:  /root/code/npm-bug/node_modules/is-even/index.js

Comment out the magic line and run it multiple times. It should only report an error the first time. If there is no error, it should output a path similar to the following

resolve:  /root/code/npm-bug/node_modules/.pnpm/[email protected]/node_modules/is-even/index.js

This seems to indicate that the createServer function causes the behavior of nodejs resolve to change. I don't know what the specific mechanism is. If anyone wants to delve into this issue, I hope it will help.

from help.

Sorry for the earlier close, @vfilatov. It's unclear how/why this issue occurs, but I've reopened the issue for tracking.

from help.

Please pay attention, this happens only on IPC, while TCP (the code below) working fine.

import fs from 'fs';
import { createServer } from 'net';
const mySocketFile = '/tmp/mysocketfile';

if (fs.statSync(mySocketFile, { throwIfNoEntry: false }))
  fs.unlinkSync(mySocketFile);

// magic line
//createServer((socket) => { }).listen(mySocketFile);
createServer((socket) => { }).listen(8080);

setTimeout(async () => {
  const isEven = await import("is-even")
  console.log("isEven: ", isEven.default(1))
});

from help.

Thanks!

@VoltrexKeyva, I believe this is a wrong-repo issue. Could you label it when you get a chance? Thank you!

Pinging you as you edited the question (and are a member of the triage team)

from help.

Hi! This repo is issues with the NodeJS core, and this looks like an issue with a package installation.

But, to answer your question, modules are usually installed with npm install <module> (or similar, depending on your package manager). Installed packages typically appear in ./node_modules/<module>, so if that folder doesn't exist, than the package is not installed.

If your experiencing an issue with pnpm, please file an issue in their repository.

Thank you!

They insist that is a nodejs bug.
pnpm/pnpm#7931 (comment)

from help.

Both forms of code run fine, so the dependencies are installed correctly

// index.js
// node ./index.js

const isEven = require('is-even')
console.log(isEven(1))

// index.mjs
// node ./index.mjs
import * as isEven from 'is-even'
console.log(isEven.default(1))

Esbuild can also bundle correctly

 esbuild ./index.mjs --bundle --platform=node

from help.

I found an interesting thing. This line of code will affect the execution results. After commenting it out, it will only report an error the first time it is run. After that, it can run correctly every time. After removing the comment, it will report an error every time it is run.

import fs from 'fs';
import { createServer } from 'net';
const mySocketFile = '/tmp/mysocketfile';

if (fs.statSync(mySocketFile, { throwIfNoEntry: false }))
  fs.unlinkSync(mySocketFile);

// magic line
createServer((socket) => { }).listen(mySocketFile);

setTimeout(async () => {
  const isEven = await import("is-even")
  console.log("isEven: ", isEven.default(1))
});

 node --version
v22.1.0

from help.

@vfilatov Can you test using node 18? On my machine node18 doesn't have this problem

from help.

@vfilatov Can you test using node 18? On my machine node18 doesn't have this problem

Yes, this particular example working on node18.
But this example is a simplified code from the original issue, which NOT working on node18 either.

sveltejs/kit#11912

from help.

I found an interesting thing. This line of code will affect the execution results. After commenting it out, it will only report an error the first time it is run. After that, it can run correctly every time. After removing the comment, it will report an error every time it is run.

import fs from 'fs';
import { createServer } from 'net';
const mySocketFile = '/tmp/mysocketfile';

if (fs.statSync(mySocketFile, { throwIfNoEntry: false }))
  fs.unlinkSync(mySocketFile);

// magic line
createServer((socket) => { }).listen(mySocketFile);

setTimeout(async () => {
  const isEven = await import("is-even")
  console.log("isEven: ", isEven.default(1))
});

 node --version
v22.1.0

Yes, that is the point!
Initially I though the problem is on the SvelteKit side, but this simplified code excludes all SvelteKit relations.
It is either pnpm or node.
As you found the (simplified) code working under node18 that makes me suspect the code might be on node core...

from help.

Hi! If you delete the package-lock and pnpm-lock files and run npm i, then test the code in the latest version (v20.1.3 for LTS), will this issue still occur?

from help.

So this probably isn't an issue with npm. What happens when you follow the same instructions but use pnpm instead?

from help.

So this probably isn't an issue with npm. What happens when you follow the same instructions but use pnpm instead?

when I use pnpm and node 20, I get the error above.
when I use pnpm and node 18, I do not get the error above.
when I use npm and any node, I do not get the error above.

from help.

So, despite what the pnpm team may have said, it really doesn't seem like an issue with Node.

from help.

So, despite what the pnpm team may have said, it really doesn't seem like an issue with Node.

It might an issue on both sides... As something changed between node18 & node20...
Would be great if somebody could simply debug the code and find that "breaking point".
May guess that bug could be fixed by either team.

from help.

Well, the change from Node.js v18 to Node.js v20 was breaking, as with major release lines, so breakages are expected, maybe the pnpm team knows?

Someone more familiar with both libraries would need to investigate this in depth, and as a short-term solution, maybe try running it with bun for now?

from help.

Marking as NPM ad this regards it vs pnpm

from help.

As this is a still not reproducible via NPM, I'm gonna go ahead and close this issue. I know this isn't the answer you wanted, but It doesn't seem actionable. If you continue to experience errors, please open a new issue here or at npm/cli.

from help.

from help.

Each one of the core developers blame the other side.

Just want to point out a few things:

1. I'm not a Node.js core collaborator. While I'm a member of the organization, my role is as issue triage and support

2. I wouldn't say I'm "blaming" the PNPM team, I just don't think this is an issue with Node.js, as (AFAICT) it's not reproducible.

CC @nodejs/npm

from help.

from help.

I've CCd the NPM team to take a look, but since this issue your describing appears to only affect PNPM (at least in the way you have described), I think that tracking it should be done in the PNPM repo. I'm not saying it's their "fault", I just think it's more actionable in that repo rather than this one.

from help.

Thanks for the info, @ahaoboy! This is certainly strange. My gut instinct would be to check how symlinks are handled, but I really don't know much about this part of core. I've CC'd relevant teams.

CC @nodejs/net - createServer weird cases
CC @nodejs/loaders - Knows the most about require

from help.

Hey everyone, I found the culprit: nodejs/node#51142.

I'm tempted to close this in favor of that, as they appear to be the same issue. LMK if you disagree.

(Duplicate of nodejs/node#51142)

from help.