module: warn on invalid package.json type field

[Shuklax]

Add validation to warn users when the "type" field in package.json contains an invalid value. Previously, values like "CommonJS" (wrong case) would silently fall back to typeless behavior. Now a clear warning message is displayed indicating the expected values are "commonjs" or "module".

Fixes: #60085

[ljharb]

tests look good to me, i'll let someone else review the C++

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.56%. Comparing base (7c85aa5) to head (e6223ee).
⚠️ Report is 28 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #60180      +/-   ##
==========================================
+ Coverage   88.52%   88.56%   +0.03%     
==========================================
  Files         703      704       +1     
  Lines      207825   208092     +267     
  Branches    40003    40012       +9     
==========================================
+ Hits       183976   184294     +318     
+ Misses      15862    15811      -51     
  Partials     7987     7987              

Files with missing lines	Coverage Δ
src/node_modules.cc	76.49% <100.00%> (+0.27%)	⬆️

... and 50 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[joyeecheung]

This should be using the usual machinery (process.emitWarning() in JS, or ProcessEmitWarning() in C++) to emit warning so that it can be suppressed with NODE_NO_WARNINGS=1 etc. or captured through event listeners by users.

[Shuklax]

Done! Changed to use ProcessEmitWarning() instead of fprintf(). Let me know if the implementation looks correct.

[joyeecheung]

Suggested change

	}
	}

[joyeecheung]

Can you add a new test file instead of appending it to the same test file? See

node/doc/contributing/writing-tests.md

Lines 30 to 32 in 3983ef6

	In principle, when adding a new test, it should be placed in a new file.
	Unless there is strong motivation to do so, refrain from appending
	new test cases to an existing file. Similar to the reproductions we ask

[Shuklax]

Done! I've added a new test file.

[mertcanaltin]

lint errors in some lines
you can make format-cpp command

[Shuklax]

@ljharb, @mertcanaltin I have done the necessary changes, please have a look at my PR as per your convenience.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[github-actions]

This pull request has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

[ljharb]

i think this should land once somebody reviews the C++

[MikeMcC399]

@Shuklax

Unfortunately you were left hanging without any feedback for quite a while. If you are interested in continuing with this PR, you'd need to:

• please rebase the branch in this PR according to the Pull requests documentation. The PR branch is more than 3000 commits behind the main branch

• Add the Signed-off-by line with your name and email address as an acknowledgement that you agree to the Developer Certificate of Origin.

• fix the linting with make lint-js-fix