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]

please confirm here: is this really needed to move live-preview dependencies here?

[spliffone]

We have two options:

1. we add them to the root package so they are automatically node_modules top level dependencies
2. we add add them to the specific dependencies to hoist patterns so the are add to node_modules top level dependencies

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

[pwuersch]

Nit: the exec here is technically not required (but can add some clarity I guess): https://pnpm.io/cli/exec#examples

[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?

[pwuersch]

@spliffone @spike-rabbit 3 hours ago, new pnpm major release v11: pnpm/pnpm@v11.0.0 (release)
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.

@spliffone locally, with a normal pnpm install using pnpm v11.0.0 I have the following file structure:

node_modules/@simpl
├── brand
└── docs-composer

Also the prepare-brand script succeeds when running pnpm prepare-brand. Did you change something in the meantime, or am I missing something?

[spliffone]

@spliffone @spike-rabbit 3 hours ago, new pnpm major release v11: pnpm/pnpm@v11.0.0 (release)
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.

@spliffone locally, with a normal pnpm install using pnpm v11.0.0 I have the following file structure:

node_modules/@simpl
├── brand
└── docs-composer

Also the prepare-brand script succeeds when running pnpm prepare-brand. Did you change something in the meantime, or am I missing something?

Yes, I started the migration again and dropped a few settings. Now it seems to work

[spliffone]

See #1900

Summary:

(+) way more powefull than npm
(+) more security
(+) releasing is less complex: no postversion
(+) stable lockfile
(+) no -- args passing
(+) better diffing because yaml lockfile

(-) more configuraiton
(-) needs to be installed
(-) tarball (requires config)

Vote:

👍 We want PNPM as the new package manager
👎 Stick to the pain we know for all the NPM lovers
 

@siemens/siemens-element-members Please share your voice on the package manager topic!

[kfenner]

See #1900

Summary:

(+) way more powefull than npm (+) more security (+) releasing is less complex: no postversion (+) stable lockfile (+) no -- args passing (+) better diffing because yaml lockfile

(-) more configuraiton (-) needs to be installed (-) tarball (requires config)

Vote:

👍 We want PNPM as the new package manager 👎 Stick to the pain we know for all the NPM lovers  

@siemens/siemens-element-members Please share your voice on the package manager topic!

@spliffone I would say the voting is complete and the majority is positive about switching to pnpm. Should we do this migration for Element v50 so we stick to npm here on the main branch until we start merging stuff for v50 and v49.x also stays on npm, OK?