Add optional PackageManagerName Option to use alternative Package Managers like Yarn #11

Closed
opened 2025-08-09 17:14:39 +00:00 by fergalmoran · 0 comments
Owner

Originally created by @KraigWalker on 10/18/2018

While the issue in #1760 can mostly be addressed by changing the package install scripts in the .csproj to use yarn instead of npm to install packages, SpaService will still use npm as the package manager of choice when executing npmScripts (i.e start)

While cross-play between yarn and npm has got a lot more stable, mixing use of npm and yarn can still lead to undesired side-effects and problems. Some users may also want to use Yarn specific features, not available in npm.

Yarn shares the same run-scripts cli api as npm thanks to its' shorter "run" alias, so all that's left to do is to specify that the user wants to use yarn to perform the command instead of npm.

This PR introduces an optional PackageManagerName Option to SPABuilder which allows the user to define the name of the package manager executable they wish to use at runtime.

This doesn't change the requirement that the executable be available in the system's PATH as is the case with npm, but if gives the user the flexibility to define which package manager they wish to use. In combination with editing the package install commands created in the spa-templates, users can now yarn, or another alternative package manager to npm.

In the absense of a specific option, the spaBuilder will continue to default to npm

A future improvement may be to also allow the user to define their own "run-scripts-alias" part, in the possible event a new killer javascript package manager comes along that has a different label for the run-script behaviour (e.g "r")

*Originally created by @KraigWalker on 10/18/2018* While the issue in #1760 can mostly be addressed by changing the package install scripts in the .csproj to use yarn instead of npm to install packages, SpaService will still use npm as the package manager of choice when executing `npmScripts` (i.e `start`) While cross-play between yarn and npm has got a lot more stable, mixing use of npm and yarn can still lead to undesired side-effects and problems. Some users may also want to use Yarn specific features, not available in npm. Yarn shares the same `run-scripts` cli api as npm thanks to its' shorter "run" alias, so all that's left to do is to specify that the user wants to use `yarn` to perform the command instead of `npm`. This PR introduces an optional `PackageManagerName` Option to `SPABuilder` which allows the user to define the name of the package manager executable they wish to use at runtime. This doesn't change the requirement that the executable be available in the system's PATH as is the case with npm, but if gives the user the flexibility to define which package manager they wish to use. In combination with editing the package install commands created in the spa-templates, users can now yarn, or another alternative package manager to npm. In the absense of a specific option, the spaBuilder will continue to default to `npm` A future improvement may be to also allow the user to define their own "run-scripts-alias" part, in the possible event a new killer javascript package manager comes along that has a different label for the `run-script` behaviour (e.g "r")
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/JavaScriptServices#11
No description provided.