Skip to content

Use 'node --run' rather than 'pnpm --silent' for running scripts - #1570

Closed
dpvc wants to merge 1 commit into
developfrom
update/package.json
Closed

dpvc wants to merge 1 commit into
developfrom
update/package.json

Conversation

@dpvc

@dpvc dpvc commented Sep 17, 2026

Copy link
Copy Markdown
Member

This PR replaces pnpm --silent with node --run in the package.json scripts. This is because pnpm always does a check of the node_modules directory for every call, so more --run is faster and more efficient. I had to make this change in the fonts repository because the latest versionof pnpm was creating unwanted node_modules directories in the font subdirectories, and was not finding the tsc from the parent node_modules, and the speed improvement was very noticeable, so I thought I'd try it here. You should see the commands that copy the locales and other assets run faster with this PR, for example.

@dpvc
dpvc requested a review from zorkow September 17, 2026 14:48
@dpvc dpvc added this to the v4.2 milestone Sep 17, 2026
@codecov

codecov Bot commented Sep 17, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.12%. Comparing base (91b8038) to head (e3560be).

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #1570   +/-   ##
========================================
  Coverage    87.12%   87.12%           
========================================
  Files          392      392           
  Lines        89187    89187           
  Branches      5063     5063           
========================================
  Hits         77706    77706           
+ Misses       11481    11461   -20     
- Partials         0       20   +20     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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.

@zorkow

zorkow commented Sep 23, 2026

Copy link
Copy Markdown
Member

I am not sure I fully understand why this change is necessary and we should discuss this in more detail, but here is an initial brain dump:

What loss of efficiency are you seeing exactly when you say pnpm always does a check of the node_modules. I am running pnpm version 12.6.0, and I can't see an issue with that. Maybe it is an issue with pnpm-workspace.yaml file in the font directories?
The advantage of using pnpm for running scripts is that it will ensure that you are running scripts against the correct dependencies. If you change branches it will update the packages if necessary (i.e., if you have a different version of a dependency in package.json).
I really don't see the efficiency argument. E.g., for me copy:locales takes nearly twice as long with node --run than with pnpm.
The lifecycle scripts are meant to be run by package mangers. Now we are using raw node invocations, which behave differently. E.g., mml3-xslt does not work for me anymore. In addition we get a mix of package managers by using npx in scripts. The handling of parameters in these scripts is always a bit fragile, but node seems to change cli parameters much more often, e.g., --run only exists since version 22. (I know the -s to --silent is a nuisance....)

@dpvc

dpvc commented Sep 23, 2026

Copy link
Copy Markdown
Member Author

For me copy:locales takes nearly twice as long with node --run than with pnpm.

That's odd, for me node --run takes about half the time: 3.01s versus 6.35s for pnpm.

For me, when I run pnpm --silent in a directory that has the package.json consisting of

{
  "scripts": {
    "test": "echo done"
  }
}

and is otherwise empty, running pnpm --silent test creates a node_modules directory containing the dot files .package-map.json and .pnpm-workspace-state-v1.json, and a pnpm-lock.yaml file. I am using pnpm version 11.24. This didn't occur in an earlier version, but I'm not sure what that was before I upgraded.

Timing using time pnpm --silent test command take .4 seconds for the first run, and .21 seconds on subsequent runs, while time node --run test takes .03 seconds, or 1/7th of the time.

So this is what I mean that pnpm checks the node_modules directory (and creates it if needed, along with pnpm-lock.yaml, even when there are no dependencies), and that node --run works faster for me.

@dpvc

dpvc commented Sep 23, 2026

Copy link
Copy Markdown
Member Author

I'm also using node v25.2.0, in case that makes a difference.

@zorkow

zorkow commented Sep 23, 2026

Copy link
Copy Markdown
Member

I've tested with node v25.8.1 and with v26.10.0 after updating to the latest version. Both slower than pnpm.

@dpvc

dpvc commented Sep 24, 2026

Copy link
Copy Markdown
Member Author

Not sure what to tell you. When I was trying to find out why pnpm was creating node_modules and pnpm-lock.yaml when I was only running a package script, not installing packages, Gemini suggested node --run as a faster alternative that didn't do the checking that pnpm does. I found that to be the case for me. Not sure why you are not seeing the same result.

@dpvc

dpvc commented Sep 24, 2026

Copy link
Copy Markdown
Member Author

E.g., mml3-xslt does not work for me anymore.

That's actually due to a bad edit on my part.

"mml3:make:xslt": "node --run xslt3 -- -t -xsl:/tmp/mml3.xsl -export:ts/input/mathml/mml3/mml3.sef.json -nogo",

should actually be

"mml3:make:xslt": "npx xslt3 -- -t -xsl:/tmp/mml3.xsl -export:ts/input/mathml/mml3/mml3.sef.json -nogo",

@dpvc

dpvc commented Sep 24, 2026

Copy link
Copy Markdown
Member Author

Closing this based on our discussion in the developers' meeting, and with the increased speed of pnpm version 12.

@dpvc dpvc closed this Sep 24, 2026
@dpvc
dpvc deleted the update/package.json branch September 24, 2026 16:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants