build(pnpm): migrate to pnpm

[spliffone]

See #1900

	PNPM	NPM
node_modules structure	Non-flat by default — only direct dependencies appear in the root of node_modules. Transitive deps are stored under .pnpm/ and symlinked.	Flat/hoisted — all packages (including transitive deps) are hoisted to the root of node_modules.
Storage model	Uses a global content-addressable store. Files are hard-linked into node_modules — only one physical copy per version across all projects. Only changed files are added when upgrading a dependency.	Copies every package into each project's node_modules.
Isolated node_modules	Yes (default)	Yes (install linked)
Ships with Node.js	No	Yes
Workspace support	Yes	Yes
Managing Node.js versions	Yes (pnpm env)	No
Catalogs (shared dep versions)	Yes (catalogs)	No
Auto-install before script run	Yes (ensure node_modules are in sync with lock file)	No
Supported JSR registry	Yes (npm-compatibility)	No
Postinstall allow list	Yes (Config dependencies)	No
Lock file stability	Stable between feature version	Unstable
Branch specific log file	Yes (Git branch lockfiles)	No
Installation hooks	Yes (.pnpmfile.mjs)	No

• PNPM is consistently faster than NPM (see PNPM Benchmark results)
• ng serve (vite) require a flat node_modules to run the dev server which require adjustments in the PNPM configuration to hoist dependencies
• The generated tarballUrl in the lock file are incorrectly for code.siemens.com

Challenges:

• Installation of code.siemens packages require the tarBallUrl

---

Documentation.
Examples.
Dashboards Demo.
Playwright report.

Coverage Reports:

• charts-ng
• dashboards-ng
• element-ng
• element-translate-ng
• maps-ng
• native-charts-ng

[gemini-code-assist]

Code Review

This pull request migrates the project from npm to pnpm as the primary package manager. The changes include updating the release configuration, documentation, and all package scripts to use pnpm commands. Additionally, a new pnpm-workspace.yaml file has been introduced, and the package.json has been updated with pnpm-specific engine requirements and dependency overrides. One review comment suggests using the $typescript variable in the pnpm overrides to ensure the TypeScript version remains synchronized with devDependencies.

[spike-rabbit]

I think we also must use the pnpm semantic-elease plugin. If not npm will install a bunch of things when releasing.
With that:

• you can use alias in the peer dependencies to workspace deps
• I hope it works with the dist packages as well somehow... may needs scripting

[chintankavathia]

I remember we discussed about using pnpm in past and one of the reason for not switching was:
So far most of the consumer projects are using yarn and npm. Since npm has the most problems with the dependency management we tend to stay on npm. Since we discover this problem earlier.

What exactly got changed now?

[spliffone]

I remember we discussed about using pnpm in past and one of the reason for not switching was: So far most of the consumer projects are using yarn and npm. Since npm has the most problems with the dependency management we tend to stay on npm. Since we discover this problem earlier.

What exactly got changed now?

@chintankavathia yes most of our consumer still use yarn or npm while almost all dependency issues are in npm environments. This PR is just an consideration to solve the frequent issue we have with the package-lock.json updates (see also #1914). Just two things:

• with npm we might figure out dependency issues with siemens lint, but since we have a mono-repo workspace I don't believe we find issues related to element.
• I thought the decision to use npm was driven by the semantic-release support

So let's discuss it in the core-meeting what is the right approach.

[spike-rabbit]

To provide some more details regarding releasing:

In pnpm workspaces one can declare (peer)dependencies using the workspace: syntax.
With that I hope we can eliminate the use of custom updating the peer dependencies.

The only problem is, that I don't know how this behaves with releasing from a dist directory, so when the actual workspace package is not the target.

[kfenner]

@spliffone @spike-rabbit 3 hours ago, new pnpm major release v11: https://github.com/pnpm/pnpm/releases/tag/v11.0.0

Thanks to @pwuersch

[pwuersch]

Hey guys, chiming in here because @kfenner was asking for some feedback from users that have used pnpm before.

pnpm has sped up our local installs quite a bit since we migrated away from Yarn already three years ago. Probably NPM has become more competitive over the years. The headlining reasons to use pnpm are quite convincing:

• Shared package store, which is faster and more efficient,
• Allow-listing of dependencies that are allowed to execute package lifecycle scripts -> mitigates almost every recent supply-chain attack we've seen, as the compromised package must be in the allowed dependencies to cause damage.

While this is already great, the real benefit in working with projects that use pnpm is the developer experience:

• Unmet peerDependencies are printed in an actually useful way,
• It still adheres to most of the vanilla npm configuration (e.g., overriding registry URLs and other settings via .npmrc),
• Very nice integration in mise-en-place or corepack, whichever you prefer,
• Amazing lockfiles with diffs you can actually read.

All in all, I enjoy working with pnpm and it's become my default choice for a package manager when using Node.js.

[spliffone]

@spliffone @spike-rabbit 3 hours ago, new pnpm major release v11: https://github.com/pnpm/pnpm/releases/tag/v11.0.0

Thanks to @pwuersch

Sadly pnpm 11 handles optionalDependencies differently and I wasn't able to link the brand dependency in the root node_modules folder which means the prepare brand script is always failing and the pipeline never succeed. So I guess we should go with version 10 at the moment.

[kfenner]

@spliffone @spike-rabbit 3 hours ago, new pnpm major release v11: https://github.com/pnpm/pnpm/releases/tag/v11.0.0
Thanks to @pwuersch

Sadly pnpm 11 handles optionalDependencies differently and I wasn't able to link the brand dependency in the root node_modules folder which means the prepare brand script is always failing and the pipeline never succeed. So I guess we should go with version 10 at the moment.

Hmm, is this a good sign?

[spike-rabbit]

Looks already pretty good. Just some hopefully minor stuff.

[spike-rabbit]

👍