Rush update issue - Githubissues

When doing rush update, it gives me the following error:

...:/mnt/c/Users/Lenovo/Documents/origin$ rush update

Rush Multi-Project Build Tool 5.40.5 - https://rushjs.io Node.js version is 14.21.2 (LTS)

Starting "rush update"

Validating package manager shrinkwrap file.

Found files in the "common/git-hooks" folder. Successfully installed these Git hook scripts: pre-commit

Trying to acquire lock for pnpm-5.18.1 Acquired lock for pnpm-5.18.1 Found pnpm version 5.18.1 in /home/marcelo/.rush/node-v14.21.2/pnpm-5.18.1

Symlinking "/mnt/c/Users/Lenovo/Documents/origin/common/temp/pnpm-local" --> "/home/marcelo/.rush/node-v14.21.2/pnpm-5.18.1" Copying /mnt/c/Users/Lenovo/Documents/origin/common/config/rush/.npmrc --> /mnt/c/Users/Lenovo/Documents/origin/common/temp/.npmrc Updating /mnt/c/Users/Lenovo/Documents/origin/common/temp/pnpmfile.js

Updating temp projects in /mnt/c/Users/Lenovo/Documents/origin/common/temp/projects

Your shrinkwrap file is missing the project "@energyweb/issuer".

Your shrinkwrap file references a project "@rush-temp/issuer-irec-api" which no longer exists.

Finished creating temporary modules (0.21 seconds)

The shrinkwrap file contains the following issues: Missing dependency "@energyweb/utils-general" (11.2.1) required by "@energyweb/issuer" Missing dependency "@ethersproject/abi" (5.3.1) required by "@energyweb/issuer" Missing dependency "@ethersproject/abstract-signer" (5.3.0) required by "@energyweb/issuer" Missing dependency "@ethersproject/contracts" (5.3.0) required by "@energyweb/issuer" Missing dependency "@ethersproject/providers" (5.3.1) required by "@energyweb/issuer" Missing dependency "@ethersproject/wallet" (5.3.0) required by "@energyweb/issuer" Missing dependency "@openzeppelin/contracts" (4.4.2) required by "@energyweb/issuer" Missing dependency "@openzeppelin/contracts-upgradeable" (4.4.2) required by "@energyweb/issuer" Missing dependency "@openzeppelin/truffle-upgrades" (1.11.0) required by "@energyweb/issuer" Missing dependency "@typechain/ethers-v5" (7.0.1) required by "@energyweb/issuer" Missing dependency "@types/chai" (4.3.0) required by "@energyweb/issuer" Missing dependency "@types/dotenv" (6.1.1) required by "@energyweb/issuer" Missing dependency "@types/mocha" (9.0.0) required by "@energyweb/issuer" Missing dependency "@types/node" (14.18.10) required by "@energyweb/issuer" Missing dependency "@types/supertest" (2.0.11) required by "@energyweb/issuer" Missing dependency "chai" (4.3.4) required by "@energyweb/issuer" Missing dependency "dotenv" (10.0.0) required by "@energyweb/issuer" Missing dependency "ethers" (5.3.1) required by "@energyweb/issuer" Missing dependency "ethlint" (1.2.5) required by "@energyweb/issuer" Missing dependency "ew-precise-proofs-js" (1.1.0) required by "@energyweb/issuer" Missing dependency "ganache-cli" (6.12.2) required by "@energyweb/issuer" Missing dependency "mocha" (9.1.3) required by "@energyweb/issuer" Missing dependency "moment" (2.29.2) required by "@energyweb/issuer" Missing dependency "shx" (0.3.3) required by "@energyweb/issuer" Missing dependency "solc" (0.8.4) required by "@energyweb/issuer" Missing dependency "solc-0.8" (npm:solc@0.8.4) required by "@energyweb/issuer" Missing dependency "solidity-docgen" (0.5.16) required by "@energyweb/issuer" Missing dependency "truffle" (5.4.26) required by "@energyweb/issuer" Missing dependency "truffle-typings" (1.0.8) required by "@energyweb/issuer" Missing dependency "ts-node" (9.1.1) required by "@energyweb/issuer" Missing dependency "typechain" (6.1.0) required by "@energyweb/issuer" Missing dependency "typescript" (4.5.4) required by "@energyweb/issuer" Missing dependency "winston" (3.3.3) required by "@energyweb/issuer" Missing dependency "winston-transport" (4.4.1) required by "@energyweb/issuer"

Deleting files from /mnt/c/Users/Lenovo/Documents/origin/common/temp/node_modules

Running "pnpm install" in /mnt/c/Users/Lenovo/Documents/origin/common/temp

Using hooks from: /mnt/c/Users/Lenovo/Documents/origin/common/temp/pnpmfile.js readPackage hook is declared. Manifests of dependencies might get overridden WARN deprecated ganache-cli@6.12.2: ganache-cli is now ganache; visit https://trfl.io/g7 for details Downloading registry.npmjs.org/ganache-cli/6.12.2: 5.8 MB/5.8 MB, done Downloading registry.npmjs.org/solc/0.8.4: 7.25 MB/7.25 MB, done WARN @nestjs/common@8.1.1 requires a peer of rxjs@^7.1.0 but none was installed. WARN @rush-temp/issuer: @typechain/ethers-v5@7.0.1 requires a peer of typechain@^5.0.0 but version 6.1.0 was installed. WARN @rush-temp/issuer: @typechain/ethers-v5@7.0.1 requires a peer of @ethersproject/bytes@^5.0.0 but none was installed. WARN @rush-temp/issuer > ethlint: solium-plugin-security@0.1.1 requires a peer of solium@^1.0.0 but none was installed. WARN @rush-temp/issuer > truffle > @truffle/preserve-to-buckets > @textile/hub > @textile/buckets: @improbable-eng/grpc-web@0.13.0 requires a peer of google-protobuf@^3.2.0 but none was installed. Packages: +1556 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARN 9 other warnings Packages are hard linked from the content-addressable store to the virtual store. Content-addressable store is at: /mnt/c/Users/Lenovo/Documents/origin/common/temp/pnpm-store/v3 Virtual store is at: node_modules/.pnpm Downloading registry.npmjs.org/truffle/5.4.26: 11 MB/11 MB, done Downloading registry.npmjs.org/@truffle/contract/4.6.14: 10.7 MB/10.7 MB, done Downloading registry.npmjs.org/typescript/4.5.4: 11.3 MB/11.3 MB, done Downloading registry.npmjs.org/solc/0.6.12: 6.63 MB/6.63 MB, done Progress: resolved 1559, reused 415, downloaded 1144, added 1556, done node_modules/.pnpm/iso-constants@0.1.2/node_modules/iso-constants: Running install script, done in 336ms node_modules/.pnpm/es5-ext@0.10.62/node_modules/es5-ext: Running postinstall script, done in 446ms node_modules/.pnpm/@apollo/protobufjs@1.2.6/node_modules/@apollo/protobufjs: Running postinstall script, done in 356ms node_modules/.pnpm/@apollo/protobufjs@1.2.7/node_modules/@apollo/protobufjs: Running postinstall script, done in 465ms node_modules/.pnpm/protobufjs@6.11.3/node_modules/protobufjs: Running postinstall script, done in 320ms node_modules/.pnpm/bufferutil@4.0.7/node_modules/bufferutil: Running install script, done in 961ms node_modules/.pnpm/keccak@3.0.3/node_modules/keccak: Running install script, done in 1s node_modules/.pnpm/leveldown@5.0.2/node_modules/leveldown: Running install script, done in 956ms node_modules/.pnpm/secp256k1@4.0.3/node_modules/secp256k1: Running install script, done in 974ms node_modules/.pnpm/sqlite3@4.2.0/node_modules/sqlite3: Running install script, failed in 24.3s .../sqlite3@4.2.0/node_modules/sqlite3 install$ node-pre-gyp install --fallback-to-build │ node-pre-gyp info it worked if it ends with ok │ node-pre-gyp info using node-pre-gyp@0.11.0 │ node-pre-gyp info using node@14.21.2 | linux | x64 │ node-pre-gyp WARN Using request for node-pre-gyp https download │ node-pre-gyp info check checked for "/mnt/c/Users/Lenovo/Documents/origin/common/temp/node_modules/.pnpm/sqlite3@4.2.0/ │ node-pre-gyp http GET https://mapbox-node-binary.s3.amazonaws.com/sqlite3/v4.2.0/node-v83-linux-x64.tar.gz │ node-pre-gyp http 403 https://mapbox-node-binary.s3.amazonaws.com/sqlite3/v4.2.0/node-v83-linux-x64.tar.gz │ node-pre-gyp WARN Tried to download(403): https://mapbox-node-binary.s3.amazonaws.com/sqlite3/v4.2.0/node-v83-linux-x64
│ node-pre-gyp WARN Pre-built binaries not found for sqlite3@4.2.0 and node@14.21.2 (node-v83 ABI, glibc) (falling back t
│ node-pre-gyp http 403 status code downloading tarball https://mapbox-node-binary.s3.amazonaws.com/sqlite3/v4.2.0/node-v
│ gyp info it worked if it ends with ok │ gyp info using node-gyp@7.1.2 │ gyp info using node@14.21.2 | linux | x64 │ gyp info ok │ gyp info it worked if it ends with ok │ gyp info using node-gyp@7.1.2 │ gyp info using node@14.21.2 | linux | x64 │ gyp info find Python using Python version 3.8.5 found at "/usr/bin/python3" │ gyp info spawn /usr/bin/python3 │ gyp info spawn args [ │ gyp info spawn args '/home/marcelo/.rush/node-v14.21.2/pnpm-5.18.1/node_modules/pnpm/dist/node_modules/node-gyp/gyp/g
│ gyp info spawn args 'binding.gyp', │ gyp info spawn args '-f', │ gyp info spawn args 'make', │ gyp info spawn args '-I', │ gyp info spawn args '/mnt/c/Users/Lenovo/Documents/origin/common/temp/node_modules/.pnpm/sqlite3@4.2.0/node_modules/s
│ gyp info spawn args '-I', │ gyp info spawn args '/home/marcelo/.rush/node-v14.21.2/pnpm-5.18.1/node_modules/pnpm/dist/node_modules/node-gyp/addon
│ gyp info spawn args '-I', │ gyp info spawn args '/home/marcelo/.cache/node-gyp/14.21.2/include/node/common.gypi', │ gyp info spawn args '-Dlibrary=shared_library', │ gyp info spawn args '-Dvisibility=default', │ gyp info spawn args '-Dnode_root_dir=/home/marcelo/.cache/node-gyp/14.21.2', │ gyp info spawn args '-Dnode_gyp_dir=/home/marcelo/.rush/node-v14.21.2/pnpm-5.18.1/node_modules/pnpm/dist/node_modules
│ gyp info spawn args '-Dnode_lib_file=/home/marcelo/.cache/node-gyp/14.21.2/<(target_arch)/node.lib', │ gyp info spawn args '-Dmodule_root_dir=/mnt/c/Users/Lenovo/Documents/origin/common/temp/node_modules/.pnpm/sqlite3@4.
│ gyp info spawn args '-Dnode_engine=v8', │ gyp info spawn args '--depth=.', │ gyp info spawn args '--no-parallel', │ gyp info spawn args '--generator-output', │ gyp info spawn args 'build', │ gyp info spawn args '-Goutput_dir=.' │ gyp info spawn args ] │ internal/modules/cjs/loader.js:905 │ throw err; │ ^ │ Error: Cannot find module 'nan' │ Require stack: │ - /mnt/c/Users/Lenovo/Documents/origin/common/temp/node_modules/.pnpm/sqlite3@4.2.0/node_modules/sqlite3/[eval] │ at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15) │ at Function.Module._load (internal/modules/cjs/loader.js:746:27) │ at Module.require (internal/modules/cjs/loader.js:974:19) │ at require (internal/modules/cjs/helpers.js:101:18) │ at [eval]:1:1 │ at Script.runInThisContext (vm.js:134:12) │ at Object.runInThisContext (vm.js:310:38) │ at internal/process/execution.js:81:19 │ at [eval]-wrapper:6:22 │ at evalScript (internal/process/execution.js:80:60) { │ code: 'MODULE_NOT_FOUND', │ requireStack: [ │ '/mnt/c/Users/Lenovo/Documents/origin/common/temp/node_modules/.pnpm/sqlite3@4.2.0/node_modules/sqlite3/[eval]'
│ ] │ } │ gyp: Call to 'node -e "require('nan')"' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
│ gyp ERR! configure error │ gyp ERR! stack Error: gyp failed with exit code: 1 │ gyp ERR! stack at ChildProcess.onCpExit (/home/marcelo/.rush/node-v14.21.2/pnpm-5.18.1/nodemodules/pnpm/dist/node
│ gyp ERR! stack at ChildProcess.emit (events.js:400:28) │ gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:285:12) │ gyp ERR! System Linux 5.15.79.1-microsoft-standard-WSL2 │ gyp ERR! command "/home/marcelo/.nvm/versions/node/v14.21.2/bin/node" "/home/marcelo/.rush/node-v14.21.2/pnpm-5.18.1/no
│ gyp ERR! cwd /mnt/c/Users/Lenovo/Documents/origin/common/temp/node_modules/.pnpm/sqlite3@4.2.0/node_modules/sqlite3
│ gyp ERR! node -v v14.21.2 │ gyp ERR! node-gyp -v v7.1.2 │ gyp ERR! not ok │ node-pre-gyp ERR! build error │ node-pre-gyp ERR! stack Error: Failed to execute '/home/marcelo/.nvm/versions/node/v14.21.2/bin/node /home/marcelo/.rus
│ node-pre-gyp ERR! stack at ChildProcess. (/mnt/c/Users/Lenovo/Documents/origin/common/temp/node_modules/
│ node-pre-gyp ERR! stack at ChildProcess.emit (events.js:400:28) │ node-pre-gyp ERR! stack at maybeClose (internal/child_process.js:1088:16) │ node-pre-gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:296:5) │ node-pre-gyp ERR! System Linux 5.15.79.1-microsoft-standard-WSL2 │ node-pre-gyp ERR! command "/home/marcelo/.nvm/versions/node/v14.21.2/bin/node" "/mnt/c/Users/Lenovo/Documents/origin/co
│ node-pre-gyp ERR! cwd /mnt/c/Users/Lenovo/Documents/origin/common/temp/node_modules/.pnpm/sqlite3@4.2.0/node_modules/sq
│ node-pre-gyp ERR! node -v v14.21.2 │ node-pre-gyp ERR! node-pre-gyp -v v0.11.0 │ node-pre-gyp ERR! not ok │ Failed to execute '/home/marcelo/.nvm/versions/node/v14.21.2/bin/node /home/marcelo/.rush/node-v14.21.2/pnpm-5.18.1/nod
└─ Failed in 24.3s node_modules/.pnpm/tiny-secp256k1@1.1.6/node_modules/tiny-secp256k1: Running install script, done in 4.2s node_modules/.pnpm/ursa-optional@0.10.2/node_modules/ursa-optional: Running install script, done in 3.1s node_modules/.pnpm/web3-bzz@1.5.3/node_modules/web3-bzz: Running postinstall script, done in 80ms node_modules/.pnpm/web3-bzz@1.8.2/node_modules/web3-bzz: Running postinstall script, done in 73ms node_modules/.pnpm/utf-8-validate@5.0.10/node_modules/utf-8-validate: Running install script, done in 833ms ERROR Command failed with exit code 1.

The command failed: /mnt/c/Users/Lenovo/Documents/origin/common/temp/pnpm-local/node_modules/.bin/pnpm install --store /mnt/c/Users/Lenovo/Documents/origin/common/temp/pnpm-store --no-prefer-frozen-lockfile ERROR: Error: The command failed with exit code 1

The rush.json doc is : /**

This is the main configuration file for Rush.
For full documentation, please see https://rushjs.io */ { "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush.schema.json",

/**
- (Required) This specifies the version of the Rush engine to be used in this repo.
- Rush's "version selector" feature ensures that the globally installed tool will
- behave like this release, regardless of which version is installed globally.
- The common/scripts/install-run-rush.js automation script also uses this version.
- NOTE: If you upgrade to a new major version of Rush, you should replace the "v5"
- path segment in the "$schema" field for all your Rush config files. This will ensure
- correct error-underlining and tab-completion for editors such as VS Code. */ "rushVersion": "5.40.5",
/**
- The next field selects which package manager should be installed and determines its version.
- Rush installs its own local copy of the package manager to ensure that your build process
- is fully isolated from whatever tools are present in the local environment.
- Specify one of: "pnpmVersion", "npmVersion", or "yarnVersion". See the Rush documentation
- for details about these alternatives. */ "pnpmVersion": "5.18.1",
// "npmVersion": "4.5.0", // "yarnVersion": "1.9.4",

/**
- Options that are only used when the PNPM package manager is selected */ "pnpmOptions": { /**
  - Specifies the location of the PNPM store. There are two possible values:
  - - "local" - use the "pnpm-store" folder in the current configured temp folder:
  - "common/temp/pnpm-store" by default.
  - - "global" - use PNPM's global store, which has the benefit of being shared
  - across multiple repo folders, but the disadvantage of less isolation for builds
  - (e.g. bugs or incompatibilities when two repos use different releases of PNPM)
  - RUSH_PNPM_STORE_PATH will override the directory that will be used as the store
  - In all cases, the store path will be overridden by the environment variable RUSH_PNPM_STORE_PATH.
  - The default value is "local". */ // "pnpmStore": "local", /**
  - If true, then Rush will add the "--strict-peer-dependencies" option when invoking PNPM.
  - This causes "rush install" to fail if there are unsatisfied peer dependencies, which is
  - an invalid state that can cause build failures or incompatible dependency versions.
  - (For historical reasons, JavaScript package managers generally do not treat this invalid
  - state as an error.)
  - The default value is false to avoid legacy compatibility issues.
  - It is strongly recommended to set strictPeerDependencies=true. */ // "strictPeerDependencies": true, /**
  - Configures the strategy used to select versions during installation.
  - This feature requires PNPM version 3.1 or newer. It corresponds to the "--resolution-strategy" command-line
  - option for PNPM. Possible values are "fast" and "fewer-dependencies". PNPM's default is "fast", but this may
  - be incompatible with certain packages, for example the "@types" packages from DefinitelyTyped. Rush's default
  - is "fewer-dependencies", which causes PNPM to avoid installing a newer version if an already installed version
  - can be reused; this is more similar to NPM's algorithm.
  - After modifying this field, it's recommended to run "rush update --full" so that the package manager
  - will recalculate all version selections. */ "resolutionStrategy": "fewer-dependencies" /**
  - If true, then rush install will report an error if manual modifications
  - were made to the PNPM shrinkwrap file without running "rush update" afterwards.
  - This feature protects against accidental inconsistencies that may be introduced
  - if the PNPM shrinkwrap file ("pnpm-lock.yaml") is manually edited. When this
  - feature is enabled, "rush update" will append a hash to the file as a YAML comment,
  - and then "rush update" and "rush install" will validate the hash. Note that this does not prohibit
  - manual modifications, but merely requires "rush update" be run
  - afterwards, ensuring that PNPM can report or repair any potential inconsistencies.
  - To temporarily disable this validation when invoking "rush install", use the
  - "--bypass-policy" command-line parameter.
  - The default value is false. */ // "preventManualShrinkwrapChanges": true, /**
  - If true, then rush install will use the PNPM workspaces feature to perform the
  - install.
  - This feature uses PNPM to perform the entire monorepo install. When using workspaces, Rush will
  - generate a "pnpm-workspace.yaml" file referencing all local projects to install. Rush will
  - also generate a "pnpmfile.js" which is used to provide preferred versions support. When install
  - is run, this pnpmfile will be used to replace dependency version ranges with a smaller subset
  - of the original range. If the preferred version is not fully a subset of the original version
  - range, it will be left as-is. After this, the pnpmfile.js provided in the repository (if one
  - exists) will be called to further modify package dependencies.
  - This option is experimental. The default value is false. */ // "useWorkspaces": true },
/**
- Older releases of the Node.js engine may be missing features required by your system.
- Other releases may have bugs. In particular, the "latest" version will not be a
- Long Term Support (LTS) version and is likely to have regressions.
- Specify a SemVer range to ensure developers use a Node.js version that is appropriate
- for your repo.
- LTS schedule: https://nodejs.org/en/about/releases/
- LTS versions: https://nodejs.org/en/download/releases/ */ "nodeSupportedVersionRange": ">=12.13.0 <13.0.0 || >=14.15.0 <15.0.0",
/**
- Odd-numbered major versions of Node.js are experimental. Even-numbered releases
- spend six months in a stabilization period before the first Long Term Support (LTS) version.
- For example, 8.9.0 was the first LTS version of Node.js 8. Pre-LTS versions are not recommended
- for production usage because they frequently have bugs. They may cause Rush itself
- to malfunction.
- Rush normally prints a warning if it detects a pre-LTS Node.js version. If you are testing
- pre-LTS versions in preparation for supporting the first LTS version, you can use this setting
- to disable Rush's warning. */ // "suppressNodeLtsWarning": false,
/**
- If you would like the version specifiers for your dependencies to be consistent, then
- uncomment this line. This is effectively similar to running "rush check" before any
- of the following commands:
- rush install, rush update, rush link, rush version, rush publish
- In some cases you may want this turned on, but need to allow certain packages to use a different
- version. In those cases, you will need to add an entry to the "allowedAlternativeVersions"
- section of the common-versions.json. */ // "ensureConsistentVersions": true,
/**
- Large monorepos can become intimidating for newcomers if project folder paths don't follow
- a consistent and recognizable pattern. When the system allows nested folder trees,
- we've found that teams will often use subfolders to create islands that isolate
- their work from others ("shipping the org"). This hinders collaboration and code sharing.
- The Rush developers recommend a "category folder" model, where buildable project folders
- must always be exactly two levels below the repo root. The parent folder acts as the category.
- This provides a basic facility for grouping related projects (e.g. "apps", "libraries",
- "tools", "prototypes") while still encouraging teams to organize their projects into
- a unified taxonomy. Limiting to 2 levels seems very restrictive at first, but if you have
- 20 categories and 20 projects in each category, this scheme can easily accommodate hundreds
- of projects. In practice, you will find that the folder hierarchy needs to be rebalanced
- occasionally, but if that's painful, it's a warning sign that your development style may
- discourage refactoring. Reorganizing the categories should be an enlightening discussion
- that brings people together, and maybe also identifies poor coding practices (e.g. file
- references that reach into other project's folders without using Node.js module resolution).
- The defaults are projectFolderMinDepth=1 and projectFolderMaxDepth=2.
- To remove these restrictions, you could set projectFolderMinDepth=1
- and set projectFolderMaxDepth to a large number. */ // "projectFolderMinDepth": 2, "projectFolderMaxDepth": 4,
/**
- Today the npmjs.com registry enforces fairly strict naming rules for packages, but in the early
- days there was no standard and hardly any enforcement. A few large legacy projects are still using
- nonstandard package names, and private registries sometimes allow it. Set "allowMostlyStandardPackageNames"
- to true to relax Rush's enforcement of package names. This allows upper case letters and in the future may
- relax other rules, however we want to minimize these exceptions. Many popular tools use certain punctuation
- characters as delimiters, based on the assumption that they will never appear in a package name; thus if we relax
- the rules too much it is likely to cause very confusing malfunctions.
- The default value is false. */ // "allowMostlyStandardPackageNames": true,
/**
- This feature helps you to review and approve new packages before they are introduced
- to your monorepo. For example, you may be concerned about licensing, code quality,
- performance, or simply accumulating too many libraries with overlapping functionality.
- The approvals are tracked in two config files "browser-approved-packages.json"
- and "nonbrowser-approved-packages.json". See the Rush documentation for details. */ // "approvedPackagesPolicy": { // /* // The review categories allow you to say for example "This library is approved for usage // in prototypes, but not in production code." // // Each project can be associated with one review category, by assigning the "reviewCategory" field // in the "projects" section of rush.json. The approval is then recorded in the files // "common/config/rush/browser-approved-packages.json" and "nonbrowser-approved-packages.json" // which are automatically generated during "rush update". // // Designate categories with whatever granularity is appropriate for your review process, // or you could just have a single category called "default". // / // "reviewCategories": [ // // Some example categories: // "production", // projects that ship to production // "tools", // non-shipping projects that are part of the developer toolchain // "prototypes" // experiments that should mostly be ignored by the review process // ], // // /* // A list of NPM package scopes that will be excluded from review. // We recommend to exclude TypeScript typings (the "@types" scope), because // if the underlying package was already approved, this would imply that the typings // are also approved. // / // // "ignoredNpmScopes": ["@types"] // },
/**
- If you use Git as your version control system, this section has some additional
- optional features you can use. */ "gitPolicy": { /**
  - Work at a big company? Tired of finding Git commits at work with unprofessional Git
  - emails such as "beer-lover@my-college.edu"? Rush can validate people's Git email address
  - before they get started.
  - Define a list of regular expressions describing allowable e-mail patterns for Git commits.
  - They are case-insensitive anchored JavaScript RegExps. Example: ".*@example.com"
  - IMPORTANT: Because these are regular expressions encoded as JSON string literals,
  - RegExp escapes need two backslashes, and ordinary periods should be "\.". */ // "allowedEmailRegExps": [ // "[^@]+@users\.noreply\.github\.com", // "travis@example\.org" // ], /**
  - When Rush reports that the address is malformed, the notice can include an example
  - of a recommended email. Make sure it conforms to one of the allowedEmailRegExps
  - expressions. */ // "sampleEmail": "mrexample@users.noreply.github.com", /**
  - The commit message to use when committing changes during 'rush publish'.
  - For example, if you want to prevent these commits from triggering a CI build,
  - you might configure your system's trigger to look for a special string such as "[skip-ci]"
  - in the commit message, and then customize Rush's message to contain that string. */ // "versionBumpCommitMessage": "Applying package updates. [skip-ci]", /**
  - The commit message to use when committing changes during 'rush version'.
  - For example, if you want to prevent these commits from triggering a CI build,
  - you might configure your system's trigger to look for a special string such as "[skip-ci]"
  - in the commit message, and then customize Rush's message to contain that string. */ // "changeLogUpdateCommitMessage": "Applying package updates. [skip-ci]" },
"repository": { /**
- The URL of this Git repository, used by "rush change" to determine the base branch for your PR.
- The "rush change" command needs to determine which files are affected by your PR diff.
- If you merged or cherry-picked commits from the master branch into your PR branch, those commits
- should be excluded from this diff (since they belong to some other PR). In order to do that,
- Rush needs to know where to find the base branch for your PR. This information cannot be
- determined from Git alone, since the "pull request" feature is not a Git concept. Ideally
- Rush would use a vendor-specific protocol to query the information from GitHub, Azure DevOps, etc.
- But to keep things simple, "rush change" simply assumes that your PR is against the "master" branch
- of the Git remote indicated by the repository.url setting in rush.json. If you are working in
- a GitHub "fork" of the real repo, this setting will be different from the repository URL of your
- your PR branch, and in this situation "rush change" will also automatically invoke "git fetch"
- to retrieve the latest activity for the remote master branch. */ // "url": "https://github.com/microsoft/rush-example", /**
- The default branch name. This tells "rush change" which remote branch to compare against.
- The default value is "master" */ // "defaultBranch": "master", /**
- The default remote. This tells "rush change" which remote to compare against if the remote URL is
- not set or if a remote matching the provided remote URL is not found. */ // "defaultRemote": "origin" },
/**
- Event hooks are customized script actions that Rush executes when specific events occur */ "eventHooks": { /**
  - The list of shell commands to run before the Rush installation starts */ "preRushInstall": [ // "common/scripts/pre-rush-install.js" ],
  /**
  - The list of shell commands to run after the Rush installation finishes */ "postRushInstall": [],
  /**
  - The list of shell commands to run before the Rush build command starts */ "preRushBuild": [],
  /**
  - The list of shell commands to run after the Rush build command finishes */ "postRushBuild": [] },
/**
- Installation variants allow you to maintain a parallel set of configuration files that can be
- used to build the entire monorepo with an alternate set of dependencies. For example, suppose
- you upgrade all your projects to use a new release of an important framework, but during a transition period
- you intend to maintain compatibility with the old release. In this situation, you probably want your
- CI validation to build the entire repo twice: once with the old release, and once with the new release.
- Rush "installation variants" correspond to sets of config files located under this folder:
- common/config/rush/variants/
- The variant folder can contain an alternate common-versions.json file. Its "preferredVersions" field can be used
- to select older versions of dependencies (within a loose SemVer range specified in your package.json files).
- To install a variant, run "rush install --variant ".
- For more details and instructions, see this article: https://rushjs.io/pages/advanced/installation_variants/ */ "variants": [ // { // / // The folder name for this variant. // / // "variantName": "old-sdk", // // / // An informative description // / // "description": "Build this repo using the previous release of the SDK" // } ],
/**
- Rush can collect anonymous telemetry about everyday developer activity such as
- success/failure of installs, builds, and other operations. You can use this to identify
- problems with your toolchain or Rush itself. THIS TELEMETRY IS NOT SHARED WITH MICROSOFT.
- It is written into JSON files in the common/temp folder. It's up to you to write scripts
- that read these JSON files and do something with them. These scripts are typically registered
- in the "eventHooks" section. */ // "telemetryEnabled": false,
/**
- Allows creation of hotfix changes. This feature is experimental so it is disabled by default.
- If this is set, 'rush change' only allows a 'hotfix' change type to be specified. This change type
- will be used when publishing subsequent changes from the monorepo. */ // "hotfixChangeEnabled": false,
/**
- (Required) This is the inventory of projects to be managed by Rush.
- Rush does not automatically scan for projects using wildcards, for a few reasons:
- 1. Depth-first scans are expensive, particularly when tools need to repeatedly collect the list.
- 1. On a caching CI machine, scans can accidentally pick up files left behind from a previous build.
- 1. It's useful to have a centralized inventory of all projects and their important metadata. */ "projects": [ // { // "packageName": "@energyweb/origin-backend-irec-app", // "projectFolder": "packages/apps/origin-backend-irec-app" // }, // { // "packageName": "@energyweb/origin-device-registry-api", // "projectFolder": "packages/devices/origin-device-registry-api" // }, // { // "packageName": "@energyweb/origin-device-registry-api-client", // "projectFolder": "packages/devices/origin-device-registry-api-client" // }, // { // "packageName": "@energyweb/origin-device-registry-irec-local-api", // "projectFolder": "packages/devices/origin-device-registry-irec-local-api" // }, // { // "packageName": "@energyweb/origin-device-registry-irec-local-api-client", // "projectFolder": "packages/devices/origin-device-registry-irec-local-api-client" // }, // { // "packageName": "@energyweb/origin-energy-api", // "projectFolder": "packages/devices/origin-energy-api" // }, // { // "packageName": "@energyweb/origin-energy-api-client", // "projectFolder": "packages/devices/origin-energy-api-client" // }, // { // "packageName": "@energyweb/origin-organization-irec-api", // "projectFolder": "packages/organizations/origin-organization-irec-api" // }, // { // "packageName": "@energyweb/origin-organization-irec-api-client", // "projectFolder": "packages/organizations/origin-organization-irec-api-client" // }, // { // "packageName": "@energyweb/origin-backend", // "projectFolder": "packages/origin-backend" // }, // { // "packageName": "@energyweb/origin-backend-client", // "projectFolder": "packages/origin-backend-client" // }, // { // "packageName": "@energyweb/origin-backend-core", // "projectFolder": "packages/origin-backend-core" // }, // { // "packageName": "@energyweb/migrations-irec", // "projectFolder": "packages/tools/migrations-irec" // }, { "packageName": "@energyweb/issuer", "projectFolder": "packages/traceability/issuer" }, // { // "packageName": "@energyweb/issuer-api", // "projectFolder": "packages/traceability/issuer-api" // }, // { // "packageName": "@energyweb/issuer-api-client", // "projectFolder": "packages/traceability/issuer-api-client" // }, // { // "packageName": "@energyweb/issuer-irec-api", // "projectFolder": "packages/traceability/issuer-irec-api" // }, // { // "packageName": "@energyweb/issuer-irec-api-client", // "projectFolder": "packages/traceability/issuer-irec-api-client" // }, { "packageName": "@energyweb/issuer-irec-api-wrapper", "projectFolder": "packages/traceability/issuer-irec-api-wrapper" } // { // "packageName": "@energyweb/exchange", // "projectFolder": "packages/trade/exchange" // }, // { // "packageName": "@energyweb/exchange-client", // "projectFolder": "packages/trade/exchange-client" // }, // { // "packageName": "@energyweb/exchange-core", // "projectFolder": "packages/trade/exchange-core" // }, // { // "packageName": "@energyweb/exchange-core-irec", // "projectFolder": "packages/trade/exchange-core-irec" // }, // { // "packageName": "@energyweb/exchange-io-erc1888", // "projectFolder": "packages/trade/exchange-io-erc1888" // }, // { // "packageName": "@energyweb/exchange-irec", // "projectFolder": "packages/trade/exchange-irec" // }, // { // "packageName": "@energyweb/exchange-irec-client", // "projectFolder": "packages/trade/exchange-irec-client" // }, // { // "packageName": "@energyweb/exchange-token-account", // "projectFolder": "packages/trade/exchange-token-account" // }, // { // "packageName": "@energyweb/origin-backend-utils", // "projectFolder": "packages/utils/origin-backend-utils" // }, // { // "packageName": "@energyweb/utils-general", // "projectFolder": "packages/utils/utils-general" // }, // { // "packageName": "@energyweb/exchange-react-query-client", // "projectFolder": "packages/api-clients/react-query/exchange" // }, // { // "packageName": "@energyweb/exchange-irec-react-query-client", // "projectFolder": "packages/api-clients/react-query/exchange-irec" // }, // { // "packageName": "@energyweb/origin-device-registry-api-react-query-client", // "projectFolder": "packages/api-clients/react-query/origin-device-registry-api" // }, // { // "packageName": "@energyweb/origin-device-registry-irec-local-api-react-query-client", // "projectFolder": "packages/api-clients/react-query/origin-device-registry-irec-local-api" // }, // { // "packageName": "@energyweb/origin-energy-api-react-query-client", // "projectFolder": "packages/api-clients/react-query/origin-energy-api" // }, // { // "packageName": "@energyweb/origin-organization-irec-api-react-query-client", // "projectFolder": "packages/api-clients/react-query/origin-organization-irec-api" // }, // { // "packageName": "@energyweb/origin-backend-react-query-client", // "projectFolder": "packages/api-clients/react-query/origin-backend" // }, // { // "packageName": "@energyweb/issuer-irec-api-react-query-client", // "projectFolder": "packages/api-clients/react-query/issuer-irec-api" // }, // { // "packageName": "ui-packages", // "projectFolder": "packages/ui" // } // { // / // The NPM package name of the project (must match package.json) // / // "packageName": "my-app", // // / // The path to the project folder, relative to the rush.json config file. // / // "projectFolder": "apps/my-app", // // / // An optional category for usage in the "browser-approved-packages.json" // and "nonbrowser-approved-packages.json" files. The value must be one of the // strings from the "reviewCategories" defined above. // / // "reviewCategory": "production", // // / // A list of local projects that appear as devDependencies for this project, but cannot be // locally linked because it would create a cyclic dependency; instead, the last published // version will be installed in the Common folder. // / // "cyclicDependencyProjects": [ // // "my-toolchain" // ], // // /* // If true, then this project will be ignored by the "rush check" command. // The default value is false. // / // // "skipRushCheck": false, // // / // A flag indicating that changes to this project will be published to npm, which affects // the Rush change and publish workflows. The default value is false. // NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both. // / // // "shouldPublish": false, // // / // Facilitates postprocessing of a project's files prior to publishing. // // If specified, the "publishFolder" is the relative path to a subfolder of the project folder. // The "rush publish" command will publish the subfolder instead of the project folder. The subfolder // must contain its own package.json file, which is typically a build output. // / // // "publishFolder": "temp/publish", // // /* // An optional version policy associated with the project. Version policies are defined // in "version-policies.json" file. See the "rush publish" documentation for more info. // NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both. // */ // // "versionPolicyName": "" // }, // // { // "packageName": "my-controls", // "projectFolder": "libraries/my-controls", // "reviewCategory": "production" // }, // // { // "packageName": "my-toolchain", // "projectFolder": "tools/my-toolchain", // "reviewCategory": "tools" // } ] }
    
    I am doing a progressive installation, adding the packages one by one. The first one I installed was: @energyweb/issuer-irec-api-wrapper, which came out ok (run rush update and rush build). Then uncomment the package: @energyweb/issuer and doing rush update again showed those errors. I appreciate a help

energywebfoundation / origin

Rush update issue #3377