Npm не может разрешить дерево зависимостей до удаления node_modules

попытайтесь понять отчет об ошибках 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

Как я понимаю последнюю часть:

  1. @angular-devkit/[email protected] найден в package.json
  2. пакет имеет одноранговую зависимость от @angular/compiler-cli@^18.0.0
  3. не удалось разрешить @angular/[email protected] (который также находится в package.json)

Почему не удается разрешить @angular/[email protected], хотя это явно действительная версия?

Как я понимаю первую часть:

  1. [email protected] найден в package.json
  2. версия 14.0.3 этого пакета имеет одноранговую зависимость от @angular-devkit/build-angular@>=15.0.0 <18.0.0
  3. (устранение ошибок, основанных на неправильном диапазоне версий)

Почему 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"
  }
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Angular и React для вашего проекта веб-разработки?
Angular и React для вашего проекта веб-разработки?
Когда дело доходит до веб-разработки, выбор правильного front-end фреймворка имеет решающее значение. Angular и React - два самых популярных...
Эпизод 23/17: Twitter Space о будущем Angular, Tiny Conf
Эпизод 23/17: Twitter Space о будущем Angular, Tiny Conf
Мы провели Twitter Space, обсудив несколько проблем, связанных с последними дополнениями в Angular. Также прошла Angular Tiny Conf с 25 докладами.
Угловой продивер
Угловой продивер
Оригинал этой статьи на турецком языке. ChatGPT используется только для перевода на английский язык.
Мое недавнее углубление в Angular
Мое недавнее углубление в Angular
Недавно я провел некоторое время, изучая фреймворк Angular, и я хотел поделиться своим опытом со всеми вами. Как человек, который любит глубоко...
Освоение Observables и Subjects в Rxjs:
Освоение Observables и Subjects в Rxjs:
Давайте начнем с основ и постепенно перейдем к более продвинутым концепциям в RxJS в Angular
0
0
132
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

@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.json? попытался удалить/переименовать package-lock.json, но результат тот же

Puschie 20.06.2024 00:54

Никогда не следует удалять package-lock.json, так как это означает неконтролируемое изменение дерева зависимостей (кошмар безопасности). Вы увидите, что люди рекомендуют это в Интернете, но это потому, что они не понимают блокировки пакетов. Хотя иногда вам может быть все равно. Вы выполнили команду, указанную в моем ответе? Если в вашем package.jsons есть устаревшие ссылки, дерево все равно будет воссоздано неправильно.

adsy 20.06.2024 01:00

Я смогу помочь больше, если вы опубликуете package.json. Но npm update --save делает то, что вы просили. Но он не выйдет волшебным образом из семвер-версий package.json. Если вам это нужно, вы хотите npm outdated.

adsy 20.06.2024 01:02

спасибо npm update --save, кажется, помогло - не был уверен, работает ли это без указания пакетов, потому что это было бы очень утомительно при переключении между коммитами.

Puschie 20.06.2024 01:08

Таким образом, вы никогда не захотите запускать это изо дня в день между ветками/коммитами. Это действительно значимое изменение в дереве операций, и его внесение будет отличаться от версий, существовавших на тот момент. Когда вы переключаете ветку/фиксацию, вам нужно просто выполнить «npm install». И это позволит установить правильные версии из файла блокировки. Похоже, что ваш CI не обеспечивает правильное управление файлами блокировки и по пути он рассинхронизировался. Измените файл блокировки -> теперь работает в новом дереве данных по сравнению с коммитом, из которого он был.

adsy 20.06.2024 01:11

Однако запустить его здесь правильно, поскольку вы активно пытаетесь изменить дерево отчетов. Затем вы зафиксируете полученный файл блокировки. Если вы попали в ситуацию, когда с некоторыми заданными package-lock.,json и package.json его невозможно было установить - это верный признак того, что кто-то внес какое-то изменение в dep без изменений файла блокировки, и CI не остановил их, что означает у вас больше нет воспроизводимых сборок.

adsy 20.06.2024 01:12

Кроме того, убедитесь, что все используют нужную (последнюю стабильную) версию NPM, и CI также использует ее. Обеспечьте это с помощью свойства engines в package.json. Старые версии NPM содержат ошибки, и несогласованность — еще одна причина, по которой вы можете попасть в такое положение. Другая проблема — если кто-то добавил package-lock.json в gitignore (очень плохо!).

adsy 20.06.2024 01:15

Я немного смущен, потому что npm update --save установил именно ту версию, которая указана в package.json, но npm install обновил некоторые версии. Кроме того, обновление nx (последняя миграция nx) привело к сбою этого разрешения, поэтому оно сломалось до того, как удалось обновить блокировку пакета. Но теперь я понимаю разницу между установкой и обновлением, так что это должно помочь мне в решении будущих проблем. Еще раз спасибо.

Puschie 20.06.2024 01:25
npm update --save — это то, что вы должны запустить, когда хотите обновить все файлы (вы делаете это здесь) и зафиксировать полученные изменения. Как ежедневный разработчик, вы не хотите всегда «работать с последними версиями». Вы хотите «запускать те же версии, что и все остальные, включая переходные пакеты». Самого по себе package.json недостаточно для получения воспроизводимых установок из-за транзитивных диапазонов зависимости. Итак, npm install использует файл блокировки. Если вы запустите npm install в известной ветке с соответствующим зафиксированным файлом блокировки, это не должно привести к каким-либо изменениям в git status. Если так, то это плохо.
adsy 20.06.2024 01:30

Если у вас есть ветки/коммиты с плохими файлами блокировки или файл блокировки, не синхронизированный с пакетом json, это действительно изменит ситуацию. Например, если в старой ветке даже нет зафиксированного файла блокировки, то вы, по сути, находитесь на Диком Западе с не идеально ограниченными версиями транзитивного отложений. Следовательно, вы обычно применяете это в CI, используя npm ci.

adsy 20.06.2024 01:30

Это может вам помочь stackoverflow.com/questions/44297803/…

adsy 20.06.2024 01:31

Другие вопросы по теме