попытайтесь понять отчет об ошибках npm и не сможете найти проблему - на удивление, удаление каталога node_modules решило ее. Мы находились в процессе обновления angular до 18+ и nx до 19+.
Found: @angular-devkit/[email protected]
node_modules/@angular-devkit/build-angular
dev @angular-devkit/build-angular@"18.0.4" from the root project
peer @angular-devkit/build-angular@">= 15.0.0 < 18.0.0" from @nx/[email protected]
node_modules/@nx/angular
@nx/angular@"19.3.0" from the root project
@nx/angular@"18.3.4" from @nrwl/[email protected]
node_modules/@nrwl/angular
@nrwl/angular@"18.3.4" from @nx/[email protected]
peer @angular-devkit/build-angular@">=15.0.0 <18.0.0" from [email protected]
node_modules/jest-preset-angular
dev jest-preset-angular@"14.1.1" from the root project
Could not resolve dependency:
dev @angular-devkit/build-angular@"18.0.4" from the root project
Conflicting peer dependency: @angular/[email protected]
node_modules/@angular/compiler-cli
peer @angular/compiler-cli@"^18.0.0" from @angular-devkit/[email protected]
node_modules/@angular-devkit/build-angular
dev @angular-devkit/build-angular@"18.0.4" from the root project
Как я понимаю последнюю часть:
Почему не удается разрешить @angular/[email protected], хотя это явно действительная версия?
Как я понимаю первую часть:
Почему npm использует старую версию jest-preset-angular и nx/angular для разрешения? похоже, что он игнорирует версии, указанные в package.json, и использует текущую установленную версию.
(удаление nod_modules для устранения проблемы с зависимостью npm мне кажется ошибкой в самом npm)
пакет.json
"dependencies": {
"@abp/ng.components": "8.1.3",
"@abp/ng.core": "8.1.3",
"@abp/ng.oauth": "8.1.3",
"@abp/ng.theme.shared": "8.1.3",
"@angular/animations": "18.0.3",
"@angular/common": "18.0.3",
"@angular/compiler": "18.0.3",
"@angular/core": "18.0.3",
"@angular/forms": "18.0.3",
"@angular/localize": "18.0.3",
"@angular/platform-browser": "18.0.3",
"@angular/platform-browser-dynamic": "18.0.3",
"@angular/router": "18.0.3",
"@ngrx/effects": "18.0.0",
"@ngrx/store": "18.0.0",
"@ngrx/operators": "18.0.0",
"@nx/angular": "19.3.0",
"@puschie286/golden-layout": "^2.6.2",
"@types/lodash-es": "^4.17.12",
"angular-oauth2-oidc": "^17.0.2",
"bootstrap-icons": "^1.11.3",
"lodash-es": "^4.17.21",
"primeicons": "^7.0.0",
"primeng": "^17.18.1",
"primeng-locale": "github:primefaces/primelocale",
"primeng-sass-theme": "github:primefaces/primeng-sass-theme",
"rxjs": "~7.8.1",
"ts-debounce": "^4.0.0",
"tslib": "^2.6.2",
"zone.js": "0.14.4"
},
"devDependencies": {
"@abp/ng.schematics": "^8.1.3",
"@abp/nx.generators": "^8.1.3",
"@angular-devkit/build-angular": "18.0.4",
"@angular-devkit/core": "18.0.4",
"@angular-devkit/schematics": "18.0.4",
"@angular-eslint/eslint-plugin": "18.0.1",
"@angular-eslint/eslint-plugin-template": "18.0.1",
"@angular-eslint/template-parser": "18.0.1",
"@angular/cli": "~18.0.0",
"@angular/compiler-cli": "18.0.3",
"@angular/language-service": "18.0.3",
"@ngrx/eslint-plugin": "18.0.0",
"@ngrx/schematics": "18.0.0",
"@ngrx/store-devtools": "18.0.0",
"@nx-dotnet/core": "^2.2.0",
"@nx/cypress": "19.3.0",
"@nx/eslint": "19.3.0",
"@nx/eslint-plugin": "19.3.0",
"@nx/jest": "19.3.0",
"@nx/js": "19.3.0",
"@nx/plugin": "19.3.0",
"@nx/web": "19.3.0",
"@nx/workspace": "19.3.0",
"@schematics/angular": "18.0.4",
"@swc-node/register": "1.9.2",
"@swc/core": "1.5.7",
"@types/jest": "^29.5.12",
"@types/node": "^20.11.17",
"@typescript-eslint/eslint-plugin": "7.3.0",
"@typescript-eslint/parser": "7.3.0",
"@typescript-eslint/utils": "^8.0.0-alpha.28",
"autoprefixer": "^10.4.17",
"cypress": "13.8.1",
"daisyui": "^4.6.3",
"eslint": "8.57.0",
"eslint-config-prettier": "^9.1.0",
"eslint-plugin-cypress": "^2.15.1",
"jasmine-marbles": "~0.9.2",
"jest": "^29.7.0",
"jest-environment-jsdom": "^29.7.0",
"jest-preset-angular": "14.1.1",
"jsonc-eslint-parser": "^2.4.0",
"nx": "19.3.0",
"postcss": "^8.4.38",
"prettier": "^3.2.5",
"tailwindcss": "^3.4.3",
"ts-jest": "^29.1.2",
"ts-node": "10.9.2",
"typescript": "5.4.3"
}





@nx/[email protected] и [email protected] оба указывают, что им нужен @angular-devkit/build-angular, то есть >= 15.0.0 < 18.0.0.
К сожалению, в этот ассортимент не входит ни одна версия 18.x.x. Последняя версия, соответствующая этому диапазону, 17.3.8 согласно семверному калькулятору NPM.
Похоже, что @nx/angular это было исправлено в https://github.com/nrwl/nx/pull/22509 . Для jest-preset-angular это было исправлено в https://github.com/thymikee/jest-preset-angular/blob/main/CHANGELOG.md#1410-2024-05-21.
Он использует старые версии, потому что у вас, вероятно, есть package-lock.json, в котором хранятся транзитивные версии этих зависимостей из предыдущей установки. Это задумано и соответствует рекомендациям, но в сложных сценариях обновления требуется дополнительная работа. Пожалуйста, смотрите package-lock.json.
С последней версией NPM вам нужно сделать что-то вроде npm update --save @nx/angular jest-preset-angular.
И убедитесь, что результирующие изменения в package-lock.json и (возможно, это изменится, только если они были прямыми зависимостями) package.json зафиксированы. Убедитесь в CI, что сборка не будет выполнена, если кто-то зафиксирует изменение, которое должно было вызвать обновление package-lock.json, но оно не было включено. Практически это означает, что в CI вы используете npm ci и никогда npm install.
И конечно, никогда не совершайте никаких обязательств node_modules.
Никогда не следует удалять package-lock.json, так как это означает неконтролируемое изменение дерева зависимостей (кошмар безопасности). Вы увидите, что люди рекомендуют это в Интернете, но это потому, что они не понимают блокировки пакетов. Хотя иногда вам может быть все равно. Вы выполнили команду, указанную в моем ответе? Если в вашем package.jsons есть устаревшие ссылки, дерево все равно будет воссоздано неправильно.
Я смогу помочь больше, если вы опубликуете package.json. Но npm update --save делает то, что вы просили. Но он не выйдет волшебным образом из семвер-версий package.json. Если вам это нужно, вы хотите npm outdated.
спасибо npm update --save, кажется, помогло - не был уверен, работает ли это без указания пакетов, потому что это было бы очень утомительно при переключении между коммитами.
Таким образом, вы никогда не захотите запускать это изо дня в день между ветками/коммитами. Это действительно значимое изменение в дереве операций, и его внесение будет отличаться от версий, существовавших на тот момент. Когда вы переключаете ветку/фиксацию, вам нужно просто выполнить «npm install». И это позволит установить правильные версии из файла блокировки. Похоже, что ваш CI не обеспечивает правильное управление файлами блокировки и по пути он рассинхронизировался. Измените файл блокировки -> теперь работает в новом дереве данных по сравнению с коммитом, из которого он был.
Однако запустить его здесь правильно, поскольку вы активно пытаетесь изменить дерево отчетов. Затем вы зафиксируете полученный файл блокировки. Если вы попали в ситуацию, когда с некоторыми заданными package-lock.,json и package.json его невозможно было установить - это верный признак того, что кто-то внес какое-то изменение в dep без изменений файла блокировки, и CI не остановил их, что означает у вас больше нет воспроизводимых сборок.
Кроме того, убедитесь, что все используют нужную (последнюю стабильную) версию NPM, и CI также использует ее. Обеспечьте это с помощью свойства engines в package.json. Старые версии NPM содержат ошибки, и несогласованность — еще одна причина, по которой вы можете попасть в такое положение. Другая проблема — если кто-то добавил package-lock.json в gitignore (очень плохо!).
Я немного смущен, потому что npm update --save установил именно ту версию, которая указана в package.json, но npm install обновил некоторые версии. Кроме того, обновление nx (последняя миграция nx) привело к сбою этого разрешения, поэтому оно сломалось до того, как удалось обновить блокировку пакета. Но теперь я понимаю разницу между установкой и обновлением, так что это должно помочь мне в решении будущих проблем. Еще раз спасибо.
npm update --save — это то, что вы должны запустить, когда хотите обновить все файлы (вы делаете это здесь) и зафиксировать полученные изменения. Как ежедневный разработчик, вы не хотите всегда «работать с последними версиями». Вы хотите «запускать те же версии, что и все остальные, включая переходные пакеты». Самого по себе package.json недостаточно для получения воспроизводимых установок из-за транзитивных диапазонов зависимости. Итак, npm install использует файл блокировки. Если вы запустите npm install в известной ветке с соответствующим зафиксированным файлом блокировки, это не должно привести к каким-либо изменениям в git status. Если так, то это плохо.
Если у вас есть ветки/коммиты с плохими файлами блокировки или файл блокировки, не синхронизированный с пакетом json, это действительно изменит ситуацию. Например, если в старой ветке даже нет зафиксированного файла блокировки, то вы, по сути, находитесь на Диком Западе с не идеально ограниченными версиями транзитивного отложений. Следовательно, вы обычно применяете это в CI, используя npm ci.
Это может вам помочь stackoverflow.com/questions/44297803/…
есть ли возможность игнорировать установленные версии и решать проблемы с помощью версий package.json? попытался удалить/переименовать package-lock.json, но результат тот же