-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Production built app's package.json dependencies are empty with pnpm@9 #22850
Comments
Experiencing the same issue |
I also have webpack failing with pnpm@9 |
Having the same issues when building with |
Having the same issue here with |
|
It looks like #22906 was started last week which will fix this. |
lost two days to this 😔 will add a comment to the PR about throwing an error when the |
support for pnpm 9 has stalled |
We've also lost several man-hours to this bug. We've created a bash script for our developers using pnpm@^9 to use with Nx. We manually added pnpm@^8.15.8 as a devDependency in our Nx repos and then use this script when we need to compatible-install.sh #!/bin/bash
# USAGE:
# Execute this script
# $ ./compatible-install.sh
#
# See this script as a stand-in for `pnpm i`
# which means arguments can be passed onto the script if required
# e.g.
# $ ./compatible-install.sh -Dw typescript@^5.4.0
installWithPnpm8Binary() {
printf "$(tput setaf 81)%s$(tput sgr0)\n\n" "Installing with pnpm 8"
pnpm exec pnpm i $@
}
testLockFileVersion() {
local lockfileVersion
read -r lockfileVersion<pnpm-lock.yaml
lockfileVersion=${lockfileVersion#*"'"}
lockfileVersion=${lockfileVersion:0:1}
[ $lockfileVersion -eq 6 ] && echo 1 || echo 0
}
init() {
local pnpmBinDir=$(pnpm bin)
local globalPnpmMajorVersion=$(pnpm -v)
globalPnpmMajorVersion=${globalPnpmMajorVersion%%.*}
if [ $globalPnpmMajorVersion -lt 9 ]; then
printf "$(tput setaf 81)%s$(tput sgr0)\n\n" "You are already using pnpm 8. Installing as per usual"
pnpm i $@
else
# If pnpm 8 binary isn't where we expect it to be install it without changing the lockfile
if [ ! -f "${pnpmBinDir}/pnpm" ]; then
pnpm i --frozen-lockfile --reporter=silent --ignore-scripts --config.dedupe-peer-dependents=false --config.recursive-install=false
fi
# do a regular install with the pnpm 8 binary located in the pnpm bin directory
installWithPnpm8Binary "$@"
fi
# Last check to make sure the lockfile version hasn't changed
if [ $(testLockFileVersion) -ne 1 ]; then
printf "\n$(tput setaf 226)%s\n$(tput setaf 160)$(tput smso) %s $(tput rmso) $(tput setaf 202)%s$(tput sgr0)\n" \
"The lockfile version has unexpectedly been updated to v9." \
"Warning!" \
"Do not commit the lockfile into git"
fi
}
if [ -z $(which pnpm) ]; then
printf "$(tput setaf 226)%s$(tput sgr0)\n" "You should at least have some version of pnpm installed to use this script"
exit 1
fi
init "$@" PS: This is an interim solution for our organization as this bug was the last straw and we're moving away from Nx. |
A workaround for an azure pipeline. There are some parts u might not need, I just copied our working solution. installPnpm() {
local PNPM_VERSION=$1
local PROJECT_PATH=$2
local NPMRC_PATH=$3
echo -e "Installing pnpm@$PNPM_VERSION in $PROJECT_PATH, using npm config:\n\n$(npm config list)\n"
rm -rf $PROJECT_PATH
mkdir -p $PROJECT_PATH
cp $NPMRC_PATH $PROJECT_PATH/.npmrc
(
cd $PROJECT_PATH
npm init -y
npm i pnpm@$PNPM_VERSION
)
local PNPM_PATH="$PROJECT_PATH/node_modules/.bin/pnpm"
local INSTALLED_PNPM_VERSION=$($PNPM_PATH --version)
if [ $INSTALLED_PNPM_VERSION != $PNPM_VERSION ]; then
echo "Failed to install specified pnpm version $PNPM_VERSION, installed version is $INSTALLED_PNPM_VERSION"
exit 1
fi
echo -e "\nInstalled pnpm@$PNPM_VERSION at $PNPM_PATH"
}
prependPath() {
local PROJECT_PATH=$1
local PNPM_PATH="$(pwd)/$PROJECT_PATH/node_modules/.bin"
echo "##vso[task.prependpath]$PNPM_PATH"
}
main() {
local PNPM_VERSION=$(node -pe "require('./package.json').packageManager.split('@')[1]")
local PROJECT_PATH='local_pnpm'
local NPMRC_PATH='.npmrc'
echo -e "Found pnpm version $PNPM_VERSION in package.json\n"
installPnpm $PNPM_VERSION $PROJECT_PATH $NPMRC_PATH
prependPath $PROJECT_PATH
}
main |
We've only found this to be an issue for local development. For our pipeline(s) on Gitlab we just use corepack to install pnpm v8. image: node:20.9.0-bullseye-slim
# ...
before_script:
- corepack enable
- corepack prepare pnpm@latest-8 --activate |
hi all, if you're affected by this issue and you would like nx to throw errors in future when the lockfile version is higher than what nx supports - please go an add a comment to the PR I looked through the code in the PR but I couldn't find any error being throw, for example if the lockfileVersion is 10 then nx should not try to proceed with faulty lockfile parsing logic |
- [X] Fix parenthesis separator detection - [x] Fix leading dash detection - [x] Migrate existing pnpm normalizer to latest code - [X] Add unit tests for v9 - [X] Dogfooding Pnpm v9 to Nx repo and agents Fixes regression with alias packages introduced via #23017 ## Benchmarks PNPM v9 Branch (migrated to branch's code) ``` Time (mean ± σ): 3.526 s ± 0.081 s [User: 0.717 s, System: 0.948 s] Range (min … max): 3.390 s … 3.714 s 20 runs ``` Master (running nx 19.1.0-beta.3) ``` Time (mean ± σ): 11.160 s ± 0.112 s [User: 0.799 s, System: 0.979 s] Range (min … max): 10.955 s … 11.379 s 20 runs ``` ## Current Behavior <!-- This is the behavior we have today --> ## Expected Behavior <!-- This is the behavior we should expect with the changes in this PR --> ## Related Issue(s) <!-- Please link the issue being fixed so it gets closed when this is merged. --> Fixes #22850 Fixes #23256 --------- Co-authored-by: James Henry <james@henry.sc>
- [X] Fix parenthesis separator detection - [x] Fix leading dash detection - [x] Migrate existing pnpm normalizer to latest code - [X] Add unit tests for v9 - [X] Dogfooding Pnpm v9 to Nx repo and agents Fixes regression with alias packages introduced via #23017 ## Benchmarks PNPM v9 Branch (migrated to branch's code) ``` Time (mean ± σ): 3.526 s ± 0.081 s [User: 0.717 s, System: 0.948 s] Range (min … max): 3.390 s … 3.714 s 20 runs ``` Master (running nx 19.1.0-beta.3) ``` Time (mean ± σ): 11.160 s ± 0.112 s [User: 0.799 s, System: 0.979 s] Range (min … max): 10.955 s … 11.379 s 20 runs ``` ## Current Behavior <!-- This is the behavior we have today --> ## Expected Behavior <!-- This is the behavior we should expect with the changes in this PR --> ## Related Issue(s) <!-- Please link the issue being fixed so it gets closed when this is merged. --> Fixes #22850 Fixes #23256 --------- Co-authored-by: James Henry <james@henry.sc>
This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context. |
Current Behavior
When using pnpm 9.0.1 and creating a production build of an app, the generated
package.json
andpnpm-lock.yaml
files contain no dependencies.This issue does not occur with pnpm@8.15.5.
Update: I've tested with the the new pnpm 9.0.2 and 9.0.5 releases and this issue still exists.
Expected Behavior
When using pnpm 9.0.1 and creating a production build of an app, the generated
package.json
andpnpm-lock.yaml
files should contain the application's dependencies.GitHub Repo
https://github.com/crbanman/nx-pnpm-9-issue
Steps to Reproduce
pnpm install
pnpm nx run my-new-app:build
dist/my-new-app/package.json
anddist/my-new-app/pnpm-lock.yaml
to see that their missing any dependenciesNx Report
Failure Logs
No response
Package Manager Version
No response
Operating System
Additional Information
No response
The text was updated successfully, but these errors were encountered: