yharaskrik
commented
2 years ago Also experiencing this. Ours looks like it is pulling in every dep, theres like 495 different packages in the dists package.json, we only have 341 in our root package.json
Closed JoA-MoS closed 2 years ago
yharaskrik
commented
2 years ago Also experiencing this. Ours looks like it is pulling in every dep, theres like 495 different packages in the dists package.json, we only have 341 in our root package.json
fahminlb33
commented
2 years ago I'm also experiencing this issue. The number of peerDependencies is too much.
Before 15
"peerDependencies": {
"multer": "1.4.5-lts.1",
"@logeect/core": "2.0.3",
"@elastic/ecs-winston-format": "^1.3.1",
"crypto-random-string": "3.3.1",
"otplib": "^12.0.1",
"winston-transport": "^4.5.0",
"axios": "^1.0.0",
"date-fns": "^2.29.3",
"date-fns-tz": "^1.3.7",
"winston": "^3.8.2",
"express": "^4.18.1",
"tslib": "^2.3.0"
},After 15
"peerDependencies": {
"multer": "1.4.5-lts.1",
"address": "1.2.0",
"agentkeepalive": "3.5.2",
"humanize-ms": "1.2.1",
"ms": "2.1.3",
"bowser": "1.9.4",
"copy-to": "2.0.1",
"dateformat": "2.2.0",
"debug": "2.6.9",
"supports-color": "5.5.0",
"has-flag": "3.0.0",
"destroy": "1.2.0",
"end-or-error": "1.0.1",
"get-ready": "1.0.0",
"is-type-of": "1.2.1",
"core-util-is": "1.0.3",
"is-class-hotfix": "0.0.6",
"isstream": "0.1.2",
"js-base64": "2.6.4",
"jstoxml": "2.2.9",
"merge-descriptors": "1.0.1",
"mime": "2.6.0",
"mz-modules": "2.1.0",
"glob": "7.2.3",
"fs.realpath": "1.0.0",
"inflight": "1.0.6",
"once": "1.4.0",
"wrappy": "1.0.2",
"inherits": "2.0.4",
"minimatch": "3.1.2",
"brace-expansion": "1.1.11",
"balanced-match": "1.0.2",
"concat-map": "0.0.1",
"path-is-absolute": "1.0.1",
"ko-sleep": "1.1.4",
"mkdirp": "0.5.6",
"minimist": "1.2.6",
"pump": "3.0.0",
"end-of-stream": "1.4.4",
"rimraf": "2.7.1",
"platform": "1.3.6",
"sdk-base": "2.0.1",
"stream-http": "2.8.2",
"builtin-status-codes": "3.0.0",
"readable-stream": "2.3.7",
"isarray": "1.0.0",
"process-nextick-args": "2.0.1",
"safe-buffer": "5.1.2",
"string_decoder": "1.1.1",
"util-deprecate": "1.0.2",
"to-arraybuffer": "1.0.1",
"xtend": "4.0.2",
"stream-wormhole": "1.1.0",
"urllib": "2.38.1",
"any-promise": "1.3.0",
"content-type": "1.0.4",
"default-user-agent": "1.0.0",
"os-name": "1.0.3",
"osx-release": "1.1.0",
"win-release": "1.1.1",
"semver": "5.7.1",
"digest-header": "0.0.1",
"utility": "0.1.11",
"ee-first": "1.1.1",
"formstream": "1.1.1",
"pause-stream": "0.0.11",
"through": "2.3.8",
"iconv-lite": "0.4.24",
"safer-buffer": "2.1.2",
"ip": "1.1.8",
"proxy-agent": "5.0.0",
"agent-base": "6.0.2",
"http-proxy-agent": "4.0.1",
"@tootallnate/once": "1.1.2",
"https-proxy-agent": "5.0.1",
"lru-cache": "5.1.1",
"yallist": "3.1.1",
"pac-proxy-agent": "5.0.0",
"get-uri": "3.0.2",
"data-uri-to-buffer": "3.0.1",
"file-uri-to-path": "2.0.0",
"fs-extra": "8.1.0",
"graceful-fs": "4.2.10",
"jsonfile": "4.0.0",
"universalify": "0.1.2",
"ftp": "0.3.10",
"xregexp": "2.0.0",
"pac-resolver": "5.0.1",
"degenerator": "3.0.2",
"ast-types": "0.13.4",
"tslib": "2.4.0",
"escodegen": "1.14.3",
"esprima": "4.0.1",
"estraverse": "4.3.0",
"esutils": "2.0.3",
"optionator": "0.8.3",
"deep-is": "0.1.4",
"fast-levenshtein": "2.0.6",
"levn": "0.3.0",
"prelude-ls": "1.1.2",
"type-check": "0.3.2",
"word-wrap": "1.2.3",
"vm2": "3.9.10",
"acorn": "8.8.0",
"acorn-walk": "8.2.0",
"netmask": "2.0.2",
"raw-body": "2.5.1",
"bytes": "3.1.2",
"http-errors": "2.0.0",
"depd": "2.0.0",
"setprototypeof": "1.2.0",
"statuses": "2.0.1",
"toidentifier": "1.0.1",
"unpipe": "1.0.0",
"socks-proxy-agent": "5.0.1",
"socks": "2.7.0",
"smart-buffer": "4.2.0",
"proxy-from-env": "1.1.0",
"qs": "6.11.0",
"side-channel": "1.0.4",
"call-bind": "1.0.2",
"function-bind": "1.1.1",
"get-intrinsic": "1.1.3",
"has": "1.0.3",
"has-symbols": "1.0.3",
"object-inspect": "1.12.2",
"escape-html": "1.0.3",
"mz": "2.7.0",
"object-assign": "4.1.1",
"thenify-all": "1.6.0",
"thenify": "3.3.1",
"unescape": "1.0.1",
"extend-shallow": "2.0.1",
"is-extendable": "0.1.1",
"xml2js": "0.4.23",
"sax": "1.2.4",
"xmlbuilder": "11.0.1",
"async": "3.2.4",
"block-stream2": "2.1.0",
"browser-or-node": "1.3.0",
"buffer-crc32": "0.2.13",
"crypto-browserify": "3.12.0",
"browserify-cipher": "1.0.1",
"browserify-aes": "1.2.0",
"buffer-xor": "1.0.3",
"cipher-base": "1.0.4",
"create-hash": "1.2.0",
"md5.js": "1.3.5",
"hash-base": "3.1.0",
"ripemd160": "2.0.2",
"sha.js": "2.4.11",
"evp_bytestokey": "1.0.3",
"browserify-des": "1.0.2",
"des.js": "1.0.1",
"minimalistic-assert": "1.0.1",
"browserify-sign": "4.2.1",
"bn.js": "5.2.1",
"browserify-rsa": "4.1.0",
"randombytes": "2.1.0",
"create-hmac": "1.1.7",
"elliptic": "6.5.4",
"brorand": "1.1.0",
"hash.js": "1.1.7",
"hmac-drbg": "1.0.1",
"minimalistic-crypto-utils": "1.0.1",
"parse-asn1": "5.1.6",
"asn1.js": "5.4.1",
"pbkdf2": "3.1.2",
"create-ecdh": "4.0.4",
"diffie-hellman": "5.0.3",
"miller-rabin": "4.0.1",
"public-encrypt": "4.0.3",
"randomfill": "1.0.4",
"es6-error": "4.1.1",
"fast-xml-parser": "3.21.1",
"strnum": "1.0.5",
"ipaddr.js": "2.0.1",
"json-stream": "1.0.0",
"lodash": "4.17.21",
"mime-types": "2.1.35",
"mime-db": "1.52.0",
"query-string": "7.1.1",
"decode-uri-component": "0.2.0",
"filter-obj": "1.1.0",
"split-on-first": "1.1.0",
"strict-uri-encode": "2.0.0",
"through2": "3.0.2",
"web-encoding": "1.1.5",
"util": "0.12.4",
"is-arguments": "1.1.1",
"has-tostringtag": "1.0.0",
"is-generator-function": "1.0.10",
"is-typed-array": "1.1.9",
"available-typed-arrays": "1.0.5",
"es-abstract": "1.20.3",
"es-to-primitive": "1.2.1",
"is-callable": "1.2.7",
"is-date-object": "1.0.5",
"is-symbol": "1.0.4",
"function.prototype.name": "1.1.5",
"define-properties": "1.1.4",
"has-property-descriptors": "1.0.0",
"object-keys": "1.1.1",
"functions-have-names": "1.2.3",
"get-symbol-description": "1.0.0",
"internal-slot": "1.0.3",
"is-negative-zero": "2.0.2",
"is-regex": "1.1.4",
"is-shared-array-buffer": "1.0.2",
"is-string": "1.0.7",
"is-weakref": "1.0.2",
"object.assign": "4.1.4",
"regexp.prototype.flags": "1.4.3",
"safe-regex-test": "1.0.0",
"string.prototype.trimend": "1.0.5",
"string.prototype.trimstart": "1.0.5",
"unbox-primitive": "1.0.2",
"has-bigints": "1.0.2",
"which-boxed-primitive": "1.0.2",
"is-bigint": "1.0.4",
"is-boolean-object": "1.1.2",
"is-number-object": "1.0.7",
"for-each": "0.3.3",
"which-typed-array": "1.1.8",
"xml": "1.0.1",
"append-field": "1.0.0",
"busboy": "1.6.0",
"streamsearch": "1.1.0",
"concat-stream": "1.6.2",
"buffer-from": "1.1.2",
"typedarray": "0.0.6",
"type-is": "1.6.18",
"media-typer": "0.3.0",
"@logeect/core": "2.1.0",
"@elastic/ecs-winston-format": "1.3.1",
"@elastic/ecs-helpers": "1.1.0",
"fast-json-stringify": "2.7.13",
"ajv": "6.12.6",
"fast-deep-equal": "3.1.3",
"fast-json-stable-stringify": "2.1.0",
"json-schema-traverse": "0.4.1",
"uri-js": "4.4.1",
"punycode": "2.1.1",
"deepmerge": "4.2.2",
"rfdc": "1.3.0",
"string-similarity": "4.0.4",
"winston-transport": "4.5.0",
"logform": "2.4.2",
"@colors/colors": "1.5.0",
"fecha": "4.2.3",
"safe-stable-stringify": "2.3.1",
"triple-beam": "1.3.0",
"axios": "1.1.3",
"follow-redirects": "1.15.2",
"form-data": "4.0.0",
"asynckit": "0.4.0",
"combined-stream": "1.0.8",
"delayed-stream": "1.0.0",
"date-fns": "2.29.3",
"date-fns-tz": "1.3.7",
"winston": "3.8.2",
"@dabh/diagnostics": "2.0.3",
"colorspace": "1.1.4",
"color": "3.2.1",
"color-convert": "1.9.3",
"color-name": "1.1.3",
"color-string": "1.9.1",
"simple-swizzle": "0.2.2",
"is-arrayish": "0.3.2",
"text-hex": "1.0.0",
"enabled": "2.0.0",
"kuler": "2.0.0",
"is-stream": "2.0.1",
"one-time": "1.0.0",
"fn.name": "1.1.0",
"stack-trace": "0.0.10",
"express": "4.17.3",
"accepts": "1.3.8",
"negotiator": "0.6.3",
"array-flatten": "1.1.1",
"body-parser": "1.19.2",
"on-finished": "2.3.0",
"content-disposition": "0.5.4",
"cookie": "0.4.2",
"cookie-signature": "1.0.6",
"encodeurl": "1.0.2",
"etag": "1.8.1",
"finalhandler": "1.1.2",
"parseurl": "1.3.3",
"fresh": "0.5.2",
"methods": "1.1.2",
"path-to-regexp": "0.1.7",
"proxy-addr": "2.0.7",
"forwarded": "0.2.0",
"range-parser": "1.2.1",
"send": "0.17.2",
"serve-static": "1.14.2",
"utils-merge": "1.0.1",
"vary": "1.1.2"
},
skrtheboss
commented
2 years ago This should have the same root cause as #12660
charsleysa
commented
2 years ago Hi @JoA-Mo,
Your docker build process is copying the root package-json.lock along with the generated package.json file.
I assume you did this so that the install of the generated package.json files used the same versions as your root project due to the generated package.json file only including top level dependencies and using version ranges.
This should no longer be needed as the generated package.json should now include all dependencies in the dependency tree with fixed versions.
yharaskrik
commented
2 years ago Hi @JoA-Mo,
Your docker build process is copying the root
package-json.lockalong with the generatedpackage.jsonfile. I assume you did this so that the install of the generatedpackage.jsonfiles used the same versions as your root project due to the generatedpackage.jsonfile only including top level dependencies and using version ranges.This should no longer be needed as the generated
package.jsonshould now include all dependencies in the dependency tree with fixed versions.
Question about this though. Our lock file has all the versions that the apps were built and tested with. But when we copy it in and use it with the generated package JSON the frozen lockfile flag causes it to fail. You said we shouldn't be copying in the lockfile anymore as everything is pinned but aren't we introducing risk because the generate package JSON is being generated with different versions from the lockfile (thus we would be running In production different versions than it was built/tested with).
JoA-MoS
commented
2 years ago @charsleysa - for docker images that might work, but there are also additional consequences related to using generatePackageJson when building and publishing an npm package. It will inflate the number of direct dependencies that your package depends on as shown in NPM.
this info:
enchorb
commented
2 years ago Doing the below code in the Dockerfile of our server and now getting error Your lockfile needs to be updated, but yarn was run with --frozen-lockfile when deploying after upgrading to v15, assuming this issue is the root cause.
I agree with the other commenters points, won't this change introduce additional risk since the versions we develop/test with locally can differ from what the docker image builds with? Reverting back to v14 until more clarification on this.
# Copy Built Code
COPY yarn.lock .
COPY dist/apps/${BUILD_APP} .
# Install Dependecies
RUN yarn install --frozen-lockfile --non-interactive --productionWe do the same process as @enchorb with the frozen lockfile flag, if the generate package json were truely correct and we didn't need out lockfile then we should be able to have our lockfile there and be able to use --frozen-lockfile successfully.
charsleysa
commented
2 years ago @JoA-MoS for publishing packages, one option could be to use this workaround posted in another issue https://github.com/nrwl/nx/issues/12660#issuecomment-1281011366 though I do think that the previous functionality should be made available using a config option for those who are publishing packages.
@enchorb @yharaskrik the generated package.json file uses version numbers from the package-lock.json file so the versions you develop/test with should be the same as the version in the docker build. You can cross check between the files to confirm that is the case. I believe the reason the lockfile doesn't work is that the version number string differs from the original package.json, e.g. original file version is ^10.2.1 generated file version is 10.3.6.
JoA-MoS
commented
2 years ago @charsleysa - thanks for providing some options, I can delay the update to 15, but wanted to report this to the nx team as I don't think this is intended behavior.
yharaskrik
commented
2 years ago Ok so this is really weird, curious if anyone has some input here, no idea if it's related to Nx or not but Nx was the only part that I updated here in this PR.
When I build my docker container now (I am not copying yarn.lock anymore) it fails when running the yarn install step
Step 5/13 : RUN yarn install --frozen-lockfile --production && yarn cache clean --all
---> [Warning] Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
---> Running in 7510889edd02
yarn install v1.22.17
warning package.json: No license field
info No lockfile found.
warning bullet@0.0.1: No license field
[1/4] Resolving packages...
warning @aws-sdk/client-s3 > @aws-sdk/eventstream-serde-browser > @aws-sdk/eventstream-marshaller@3.78.0: The package @aws-sdk/eventstream-marshaller has been renamed to @aws-sdk/eventstream-codec. Please install the renamed package.
warning @aws-sdk/client-s3 > @aws-sdk/eventstream-serde-node > @aws-sdk/eventstream-marshaller@3.78.0: The package @aws-sdk/eventstream-marshaller has been renamed to @aws-sdk/eventstream-codec. Please install the renamed package.
warning @aws-sdk/client-s3 > @aws-sdk/eventstream-serde-browser > @aws-sdk/eventstream-serde-universal > @aws-sdk/eventstream-marshaller@3.78.0: The package @aws-sdk/eventstream-marshaller has been renamed to @aws-sdk/eventstream-codec. Please install the renamed package.
warning @aws-sdk/eventstream-marshaller@3.78.0: The package @aws-sdk/eventstream-marshaller has been renamed to @aws-sdk/eventstream-codec. Please install the renamed package.
warning @nestjs/graphql > subscriptions-transport-ws@0.11.0: The `subscriptions-transport-ws` package is no longer maintained. We recommend you use `graphql-ws` instead. For help migrating Apollo software to `graphql-ws`, see https://www.apollographql.com/docs/apollo-server/data/subscriptions/#switching-from-subscriptions-transport-ws For general help using `graphql-ws`, see https://github.com/enisdenjo/graphql-ws/blob/master/README.md
warning querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
warning subscriptions-transport-ws@0.11.0: The `subscriptions-transport-ws` package is no longer maintained. We recommend you use `graphql-ws` instead. For help migrating Apollo software to `graphql-ws`, see https://www.apollographql.com/docs/apollo-server/data/subscriptions/#switching-from-subscriptions-transport-ws For general help using `graphql-ws`, see https://github.com/enisdenjo/graphql-ws/blob/master/README.md
warning url > querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
warning uuid@3.3.2: Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details.
[2/4] Fetching packages...
[3/4] Linking dependencies...
warning " > @firebase/database-compat@0.1.5" has unmet peer dependency "@firebase/app-compat@0.x".
warning "firebase-admin > @firebase/database-compat@0.1.8" has unmet peer dependency "@firebase/app-compat@0.x".
<--- Last few GCs --->
[9:0x7f9979fed2e0] 95315 ms: Scavenge (reduce) 253.6 (256.5) -> 253.5 (258.0) MB, 2.7 / 0.0 ms (average mu = 0.313, current mu = 0.059) task
[9:0x7f9979fed2e0] 95646 ms: Mark-sweep (reduce) 254.2 (257.3) -> 252.6 (257.8) MB, 268.1 / 0.0 ms (+ 38.4 ms in 21 steps since start of marking, biggest step 20.7 ms, walltime since start of marking 340 ms) (average mu = 0.312, current mu = 0.310) al
<--- JS stacktrace --->
FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
Aborted (core dumped)
The command '/bin/sh -c yarn install --frozen-lockfile --production && yarn cache clean --all' returned a non-zero code: 134
Exited with code exit status 134Looks like a memory issue, again, the only thing that change between this build and a previous one is that I updated Nx and the generated package json changed. Our other apps successfully build it's just this one fails.
The one failing (now) has 702 ish packages in the package.json, the one that succeeds only has like 65. This was working before so I don't realllly want to crank the resources up on CI to get past this. Any docker experts around here that can point me in the direction of what I can do so the new way Nx generates the package.json will work for us?
yharaskrik
commented
2 years ago Not sure if the container will run after this (i don't see why not) but this little script that is ran after the build seems to have solved my memory issue woes.
const { readFileSync, writeFileSync } = require('fs');
const { join } = require('path');
/**
* @description Trim dependencies from the generated built package.json so it's only the first level of
* dependencies and not everything.
*
* @type {any}
*/
const packageJson = JSON.parse(readFileSync(join(__dirname, '../package.json'), { encoding: 'utf8' }));
const distPackageJson = JSON.parse(
readFileSync(join(__dirname, '../dist/apps/<app>/package.json'), { encoding: 'utf8' })
);
Object.keys(distPackageJson['dependencies']).forEach((key) => {
if (!packageJson['dependencies'][key]) {
distPackageJson['dependencies'][key] = undefined;
}
});
writeFileSync(join(__dirname, '../dist/apps/<app>/package.json'), JSON.stringify(distPackageJson));@yharaskrik - I am curious do you get this error outside of the container? IE copy the /dist/apps/<app> directory to some location outside of your repo and run the same command from the docker file in that directory?
yharaskrik
commented
2 years ago @yharaskrik - I am curious do you get this error outside of the container? IE copy the
/dist/apps/<app>directory to some location outside of your repo and run the same command from the docker file in that directory?
I can try it but I doubt it. I have a brand new MacBook pro M2 with a ton of RAM.
yharaskrik
commented
2 years ago @yharaskrik - I am curious do you get this error outside of the container? IE copy the
/dist/apps/<app>directory to some location outside of your repo and run the same command from the docker file in that directory?
Installs fine on my local machine.
yharaskrik
commented
2 years ago Hi @JoA-Mo,
Your docker build process is copying the root
package-json.lockalong with the generatedpackage.jsonfile. I assume you did this so that the install of the generatedpackage.jsonfiles used the same versions as your root project due to the generatedpackage.jsonfile only including top level dependencies and using version ranges.This should no longer be needed as the generated
package.jsonshould now include all dependencies in the dependency tree with fixed versions.
Something isn't working right. Our root package.json defines nanoid as ^3.1.20 but the generated package json for our app used 2.1.11 which breaks our server once deployed.
Is there any plans to revert this generate package json change? If not I will need to write some more scripts to fix this ourselves as I don't think I can trust the generated one.
leon
commented
2 years ago Any news on this?
After updating to nx 15 all my express apps using generatePackageJson: true now contain a whole bunch of dependencies which where not getting added when using v14
When comparing the old output and the new, It looks like v15 is including all the peer dependencies as top level dependencies instead.
So I'm getting a lot of:
"@firebase/analytics": "0.8.3",
"@firebase/analytics-compat": "0.1.16",
"@firebase/analytics-types": "0.7.0",
"@firebase/app": "0.8.2",
"@firebase/app-check": "0.5.15",
"@firebase/app-check-compat": "0.2.15",
"@firebase/app-check-interop-types": "0.1.0",
"@firebase/app-check-types": "0.4.0",
"@firebase/app-compat": "0.1.37",
"@firebase/app-types": "0.8.0",
"@firebase/auth": "0.20.10",
"@firebase/auth-compat": "0.2.23",
"@firebase/auth-interop-types": "0.1.6",
"@firebase/auth-types": "0.11.0",
"@firebase/component": "0.5.20",
"@firebase/database": "0.13.9",
"@firebase/database-compat": "0.2.9",
"@firebase/database-types": "0.9.16",
"@firebase/firestore": "3.7.1",
"@firebase/firestore-compat": "0.2.1",
"@firebase/firestore-types": "2.5.0",
"@firebase/functions": "0.8.7",
"@firebase/functions-compat": "0.2.7",
"@firebase/functions-types": "0.5.0",
"@firebase/installations": "0.5.15",
"@firebase/installations-compat": "0.1.15",
"@firebase/installations-types": "0.4.0",
pmosconi
commented
2 years ago Hi,
in my case generatePackageJson: true is also adding the wrong dependency of uuid package:
in root package.json: "uuid": "^9.0.0",
in dist/apps/api/package.json: "uuid": "^8.0.0"
There migh be other packages, but in this case the application is using a function that was deployed in uuid version 8.3.0, so it is cashing.
Interim solution: added yarn add uuid@^9.0.0 --production --no-lockfile to deployment script
Hope this helps.
yharaskrik
commented
2 years ago Hi, in my case
generatePackageJson: trueis also adding the wrong dependency of uuid package: in root package.json:"uuid": "^9.0.0", in dist/apps/api/package.json:"uuid": "^8.0.0"There migh be other packages, but in this case the application is using a function that was deployed in uuid version 8.3.0, so it is cashing.
Interim solution: added
yarn add uuid@^9.0.0 --production --no-lockfileto deployment scriptHope this helps.
Yes, I was also getting incorrect versions of packages used.
for everyone here, after you run build with the flag you can use this flag to fix your package.json
const { readFileSync, writeFileSync } = require('fs');
const { join } = require('path');
const app = process.argv[2];
const packageJson = JSON.parse(readFileSync(join(__dirname, '../package.json'), { encoding: 'utf8' }));
const distPackageJson = JSON.parse(
readFileSync(join(__dirname, `../dist/apps/${app}/package.json`), { encoding: 'utf8' })
);
Object.keys(distPackageJson['dependencies']).forEach((key) => {
const version = packageJson['dependencies'][key];
if (!version) {
distPackageJson['dependencies'][key] = undefined;
} else {
distPackageJson['dependencies'][key] = version;
}
});
writeFileSync(join(__dirname, `../dist/apps/${app}/package.json`), JSON.stringify(distPackageJson));then run it with node filename.js <appname>
PointSingularity
commented
2 years ago Had the same thing happen with a version of axios. It might be adding packages NX itself is using.
capJavert
commented
2 years ago @FrozenPandaz @meeroslav is this something that is gonna be fixed/reverted to the 14.x behaviour or are you keeping it? I just think we all need some feedback because currently there is no valid solution to this. Thanks!
If I am looking at it correctly this change in behaviour was made in https://github.com/nrwl/nx/pull/12185
meeroslav
commented
2 years ago Hey @capJavert,
We will not revert the code to v14, but we are working on the solution for this case.
In v14 we were keeping the version ranges as they were in package.json, which oftentimes caused unexpected errors when versions changed. The v15 uses fixed versions.
The additional dependencies issue is something we will investigate and will get back to you as soon as possible.
yharaskrik
commented
2 years ago Hey @meeroslav thanks for your reply. One thing I will note is that there is one other issue more than the additional deps issue. There are cases where the version in the generated package json is wrong compared to the root package.json (and thus the lock file).
https://github.com/nrwl/nx/issues/12675#issuecomment-1289241554
https://github.com/nrwl/nx/issues/12675#issuecomment-1287239178
For the one that happened to me nanoid once I deployed my server it failed to start up as the version of nanoid that was installed was behind the version the app was built and tested with (by a major) so it just crashed. Which I believe is a bug based on how we were told it should work here: https://github.com/nrwl/nx/issues/12675#issuecomment-1283380735
meeroslav
commented
2 years ago That should be fixed as well. Please try the following:
Go to node_modules/@nrwl/workspace/src/utilities/create-package-json.js and add wrap lines 57-59 in else branch.
Should look like this:
if (node) {
list[node.data.packageName] = node.data.version;
recursivelyCollectPeerDependencies(node.name, graph, list);
} else {
(_a = graph.dependencies[projectName]) === null || _a === void 0 ? void 0 : _a.forEach((dep) => {
findAllNpmDeps(dep.target, graph, list, seen);
});
}The version will be fixed, though, so something like typescript: ^4.8.0 would probably become typescript: 4.8.4
yharaskrik
commented
2 years ago Looks like that worked (just by looking at what was generated) will still need to push to CI to check it all builds right.
JoA-MoS
commented
2 years ago the process of copying the root package-lock.json and running CI still doesn't work.
#9 [5/5] RUN npm ci --ignore-scripts --omit=dev
#9 5.352 npm ERR! code EUSAGE
#9 5.357 npm ERR!
#9 5.357 npm ERR! `npm ci` can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.
#9 5.358 npm ERR!
#9 5.359 npm ERR! Invalid: lock file's axios@0.26.1 does not satisfy axios@0.21.4
#9 5.359 npm ERR! Invalid: lock file's jsonc-parser@3.2.0 does not satisfy jsonc-parser@3.1.0
#9 5.359 npm ERR! Invalid: lock file's qs@6.11.0 does not satisfy qs@6.5.3
#9 5.360 npm ERR!
#9 5.360 npm ERR! Clean install a projectI don't think running install is a valid option either as it will not ensure child dependencies are at the exact same version
JoA-MoS
commented
2 years ago To give some background we started working around this in v8 of nx. With lots of conversation specifically around nestjs which you can see here https://github.com/nestjs/nest/issues/1706#issuecomment-579248915. Where a solution was provided using some custom webpack config. As well as a solution provided in an nx issue here https://github.com/nrwl/nx/issues/1518#issuecomment-533555445
Then the generatePackageJson flag was introduced and we could get rid of all those solutions in the issues above, which made many people happy.
The main issue is that we need a way to 100% ensure that all dependencies and child dependencies are at the exact version of the dependencies during test, running npm install may pull a higher in range version of a child dependency even if the direct dependency is pinned.
I am still hoping that we will be able to copy the root package-lock.json into the dist/apps/<app> directory to and run npm ci
meeroslav
commented
2 years ago @JoA-MoS, we are working on the lock file pruning (currently only possible with yarn) so once that is in you will be able to create a pruned lock file based on your project's package.json, instead of copying over the root one. Hopefully, in a few days, we'll have a solution for npm at least.
I'm surprised though how this worked so far. I expect the project's package.json always potentially not to match the root lock file since the package ranges might not match and it only contains a subset of packages from the root.
That being said, I checked again on your repo and the version in the lock file, in node_modules and in the generated package.json match so the installation went successfully for me.
Can you check if the version for axios in node_modules is 0.21.1 because that's what the lock file has?
If not, remove your node_modules and re-run the npm ci on the root, because it seems that your node_modules has a newer version (0.21.4 is referenced in @nrwl/nx-cloud and is a transitive dependency).
meeroslav
commented
2 years ago @JoA-MoS if this continues to be the problem on your side even after clean deps reinstall then I would need the copy of your nxdeps.json (from node_modules/.cache/nx) to investigate how your versions differ in the graph.
JoA-MoS
commented
2 years ago @meeroslav installing a subset of the package-lock.json I believe is a feature of npm although I can't find it documented. In npm workspaces you can copy only the root package.json and a specific workspace package.json and the root package-lock.json and run npm ci --workspace=my-project and it does not install the other packages indicated in the package-lock.json. Here is another thread - https://github.com/nrwl/nx/issues/9761#issuecomment-1093313090 where a number of people are saying they depend on this behavior.
JoA-MoS
commented
2 years ago @meeroslav - I could not reproduce it working successfully. Here are my axios deps for the repo. Is it any chance that you did not checkout the nx-15-update branch and run npm ci
here is my nxdeps.json
meeroslav
commented
2 years ago I did check out your branch and based on your npm report, the version in the dist/apps/campsite-watcher/package.json should be 0.26.1. Your nxdeps.json is as expected so I have no idea what could be wrong.
Can you make sure to run npx nx instead of using global (if any) nx? This is the only thing that comes to my mind. The only difference between your machine and mine is that I have arm64 instead of x64, but that should not make any difference.
This is what gets generated for me with the fix applied (see full flow below):
~ npx nx build campsite-watcher --skip-nx-cache
> nx run campsite-watcher:build
chunk (runtime: main) main.js (main) 11.8 KiB [entry] [rendered]
webpack compiled successfully (459b1b0db1de35d0)
————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
> NX Successfully ran target build for project campsite-watcher (2s)
See Nx Cloud run details at https://nx.app/runs/jYLDQ2kh02
~ cat dist/apps/campsite-watcher/package.json
{
"scripts": {
"start": "node main.js",
"release": "semantic-release-plus"
},
"dependencies": {
"axios": "0.26.1",
"dayjs": "1.11.5",
"jsonc-parser": "3.2.0",
"nodemailer": "6.8.0",
"qs": "6.11.0",
"tslib": "2.4.0"
},
"main": "main.js"
}
~ cp package-lock.json dist/apps/campsite-watcher
~ cd dist/apps/campsite-watcher
~ npm ci
added 14 packages, and audited 15 packages in 2s
7 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilitiesI did the following
rm -rf node_modules
npm ci
# manually updated create-package.json
npx nx run campsite-watcher:docker-build:production --skip-nx-cache with the same failed result on npm ci. Is there something I need from 15.0.1 that changes the behavior for generating the package.json. I noticed you generated has different versions than mine
In the nxdeps.json this section seems wrong
package-lock.json
generated package.json
Here is my dist/apps/campsite-watcher directory with the package-lock.json copied - it doesn't work for me to run npm ci in this directory
JoA-MoS
commented
2 years ago I updated to 15.0.3 and made the manual change to create-package-json.js and still have the same result
aniravi24
commented
2 years ago Noticing a similar issue with my project as well. I have a package that I pinned to the latest version, and there's another package that also happens to rely on an older version of this same package (which it has also pinned in its dependency list). In the yarn.lock file, there's two pinned versions of the package, and NX chose the first of two (i.e. the lowest) version instead of the version pinned in the workspace package.json. Is that the intended behavior? It also happens to be the case that the other package I mentioned that pins the lower version of this package is not actually used in the project where I'm generating the package.json, but I think that's coincidental since I have one package.json at the root to manage all dependencies in the workspace.
JoA-MoS
commented
2 years ago @meeroslav - I don't think this is fully fixed. the 15.0.4 changes reduced the number of dependencies being populated into the generated package.json but the version of those packages seems to match the lowest referenced version in the repo. I see you pulled my repo and were able to get a compatible package.json but I cannot reproduce this. I have even re-cloned my repo into a new folder and started clean and still have this issue.
here is my updated nx-report of it not working
I am curious if anyone sees anything of relevance that could cause this.
meeroslav
commented
2 years ago Noticing a similar issue with my project as well. I have a package that I pinned to the latest version, and there's another package that also happens to rely on an older version of this same package (which it has also pinned in its dependency list). In the yarn.lock file, there are two pinned versions of the package, and NX chose the first of two (i.e. the lowest) versions instead of the version pinned in the workspace package.json. Is that the intended behavior? It also happens to be the case that the other package I mentioned that pins the lower version of this package is not actually used in the project where I'm generating the package.json, but I think that's coincidental since I have one package.json at the root to managing all dependencies in the workspace.
We are checking which of these two versions is hoisted in the node_modules. If you open the node_modules/your_package/package.json you will likely see that version matches the lower version. It comes down to your package manager and what they choose to be hoisted.
For example, let's say your package.json has a dependency on axios: 0.27.2 and you also have @nrwl/nx-cloud: latest which depends on axios: 0.21.4. Your package manager might decide that 0.21.4 is hoisted, so when you try to import axios in your code you are actually importing 0.21.4 version.
There are ways to enforce the version in the package.json by specifying resolutions, e.g.:
{
"dependencies": {
"axios": "~0.26.0", // this resolves axios to 0.26.1
"@nrwl/nx-cloud": "latest" // this resolves axios to 0.21.4
},
"resolutions": {
"axios": "0.27.2" // this is that actual version that will be installed
}
}@meeroslav - I don't think this is fully fixed. the 15.0.4 changes reduced the number of dependencies being populated into the generated package.json but the version of those packages seems to match the lowest referenced version in the repo. I see you pulled my repo and were able to get a compatible package.json but I cannot reproduce this. I have even re-cloned my repo into a new folder and started clean and still have this issue.
here is my updated nx-report of it not working
NOT working on my mac os - nx report - (click to expand) WORKING on my windows WSL - nx report - (click to expand) I am curious if anyone sees anything of relevance that could cause this.
Can you try to run npm cache clean --force after the removal of node modules and before the installation with npm ci?
As for the version referenced, please check my reply to @aniravi24 above.
JoA-MoS
commented
2 years ago npm cache clean --force and npm ci didn't work. Here are the steps I took that seem to work to get it working locally but it is still failing on my github actions / nx-cloud
rm -rf node_modules
rm package-lock.json
npm cache clean --force
npm install --prefer-onlineyes some of those are probably redundant
So that made it work locally (https://cloud.nx.app/runs/SxY5eJbag6) but it is still failing on the CI server (https://cloud.nx.app/runs/xjI2uf1zVy)
aniravi24
commented
2 years ago @meeroslav I forgot about this yarn behavior. What's interesting in my scenario is that while the oldest version shows up first in the yarn.lock, the actual version in the node_modules directory is the newest one, not the oldest one that Nx is pulling. As you said, that's likely just package manager dependent though. I use yarn 3 with the node-modules linker.
yharaskrik
commented
2 years ago Just updated to Nx 15.0.4 and I am still seeing the wrong versions being added. For example:
Generated:
"uuid": "3.3.2",
"redis": "3.1.2",
"mime-types": "2.1.29",
"nanoid": "2.1.11",
"graphql-ws": "5.5.5",
"axios": "0.19.0",Root:
"uuid": "^8.3.2",
"redis": "^3.0.2", (lockfile has 3.0.2 in it)
"mime-types": "^2.1.35", (lockfile has 2.1.35 in it)
"nanoid": "^3.1.20",
"graphql-ws": "^5.8.1",
"axios": "0.27.2",lockfile
axios@0.19.0:
version "0.19.0"
resolved "https://registry.yarnpkg.com/axios/-/axios-0.19.0.tgz#8e09bff3d9122e133f7b8101c8fbdd00ed3d2ab8"
integrity sha512-1uvKqKQta3KBxIz14F2v06AEHZ/dIoeKfbTRkK1E5oqjDnuEerLmYTgJB5AiQZHJcljpg1TuRzdjDR06qNk0DQ==
dependencies:
follow-redirects "1.5.10"
is-buffer "^2.0.2"
axios@0.21.1, axios@^0.21.1:
version "0.21.1"
resolved "https://registry.yarnpkg.com/axios/-/axios-0.21.1.tgz#22563481962f4d6bde9a76d516ef0e5d3c09b2b8"
integrity sha512-dKQiRHxGD9PPRIUNIWvZhPTPpl1rf/OxTYKsqKUDjBwYylTvV7SjSHJb9ratfyzM6wCdLCOYLzs73qpg5c4iGA==
dependencies:
follow-redirects "^1.10.0"
axios@0.27.2:
version "0.27.2"
resolved "https://registry.yarnpkg.com/axios/-/axios-0.27.2.tgz#207658cc8621606e586c85db4b41a750e756d972"
integrity sha512-t+yRIyySRTp/wua5xEr+z1q60QmLq8ABsS5O9Me1AsE5dfKqgnCFzwiCZZ/cGNd1lq4/7akDWMxdhVlucjmnOQ==
dependencies:
follow-redirects "^1.14.9"
form-data "^4.0.0"
axios@^0.19.2:
version "0.19.2"
resolved "https://registry.yarnpkg.com/axios/-/axios-0.19.2.tgz#3ea36c5d8818d0d5f8a8a97a6d36b86cdc00cb27"
integrity sha512-fjgm5MvRHLhx+osE2xoekY70AhARk3a6hkN+3Io1jc00jtquGvxYlKlsFUhmUET0V5te6CcZI7lcv2Ym61mjHA==
dependencies:
follow-redirects "1.5.10"
axios@^0.21.2:
version "0.21.4"
resolved "https://registry.yarnpkg.com/axios/-/axios-0.21.4.tgz#c67b90dc0568e5c1cf2b0b858c43ba28e2eda575"
integrity sha512-ut5vewkiu8jjGBdqpM44XxjuCjq9LAKeHVmoVfHVzy8eHgxxq8SbAVQNovDA8mVi05kP0Ea/n/UzcSHcTJQfNg==
dependencies:
follow-redirects "^1.14.0"
axios@^0.25.0:
version "0.25.0"
resolved "https://registry.yarnpkg.com/axios/-/axios-0.25.0.tgz#349cfbb31331a9b4453190791760a8d35b093e0a"
integrity sha512-cD8FOb0tRH3uuEe6+evtAbgJtfxr7ly3fQjYcMcuPlgkwVS9xboaVIpcDV+cYQe+yGykgwZCs1pzjntcGa6l5g==
dependencies:
follow-redirects "^1.14.7"
axios@^1.0.0:
version "1.1.2"
resolved "https://registry.yarnpkg.com/axios/-/axios-1.1.2.tgz#8b6f6c540abf44ab98d9904e8daf55351ca4a331"
integrity sha512-bznQyETwElsXl2RK7HLLwb5GPpOLlycxHCtrpDR/4RqqBzjARaOTo3jz4IgtntWUYee7Ne4S8UHd92VCuzPaWA==
dependencies:
follow-redirects "^1.15.0"
form-data "^4.0.0"
proxy-from-env "^1.1.0"
graphql-ws@5.5.5, graphql-ws@^5.4.1:
version "5.5.5"
resolved "https://registry.yarnpkg.com/graphql-ws/-/graphql-ws-5.5.5.tgz#f375486d3f196e2a2527b503644693ae3a8670a9"
integrity sha512-hvyIS71vs4Tu/yUYHPvGXsTgo0t3arU820+lT5VjZS2go0ewp2LqyCgxEN56CzOG7Iys52eRhHBiD1gGRdiQtw==
graphql-ws@^5.8.1:
version "5.8.1"
resolved "https://registry.yarnpkg.com/graphql-ws/-/graphql-ws-5.8.1.tgz#daf72534b8a169a272e730fa4f3ce0e6d04e2883"
integrity sha512-UVf/fxlHultC1+12tX9ShTIipqQFNZ96g7N51RFQlk7MFPsDUUMCR3QXVEzHEd5xlTp16rs5vCyfBljvcPN3fA==
graphql-ws@^5.9.0:
version "5.11.2"
resolved "https://registry.yarnpkg.com/graphql-ws/-/graphql-ws-5.11.2.tgz#d5e0acae8b4d4a4cf7be410a24135cfcefd7ddc0"
integrity sha512-4EiZ3/UXYcjm+xFGP544/yW1+DVI8ZpKASFbzrV5EDTFWJp0ZvLl4Dy2fSZAzz9imKp5pZMIcjB0x/H69Pv/6w==
redis@^3.0.0:
version "3.1.2"
resolved "https://registry.npmjs.org/redis/-/redis-3.1.2.tgz#766851117e80653d23e0ed536254677ab647638c"
integrity sha512-grn5KoZLr/qrRQVwoSkmzdbw6pwF+/rwODtrOr6vuBRiR/f3rjSTGupbF90Zpqm2oenix8Do6RV7pYEkGwlKkw==
dependencies:
denque "^1.5.0"
redis-commands "^1.7.0"
redis-errors "^1.2.0"
redis-parser "^3.0.0"
redis@^3.0.2:
version "3.0.2"
resolved "https://registry.yarnpkg.com/redis/-/redis-3.0.2.tgz#bd47067b8a4a3e6a2e556e57f71cc82c7360150a"
integrity sha512-PNhLCrjU6vKVuMOyFu7oSP296mwBkcE6lrAjruBYG5LgdSqtRBoVQIylrMyVZD/lkF24RSNNatzvYag6HRBHjQ==
dependencies:
denque "^1.4.1"
redis-commands "^1.5.0"
redis-errors "^1.2.0"
redis-parser "^3.0.0"
mime-types@^2.0.8, mime-types@^2.1.12, mime-types@^2.1.27, mime-types@~2.1.17, mime-types@~2.1.19, mime-types@~2.1.24:
version "2.1.29"
resolved "https://registry.yarnpkg.com/mime-types/-/mime-types-2.1.29.tgz#1d4ab77da64b91f5f72489df29236563754bb1b2"
integrity sha512-Y/jMt/S5sR9OaqteJtslsFZKWOIIqMACsJSiHghlCAyhf7jfVYjKBmLiX8OgpWeW+fjJ2b+Az69aPFPkUOY6xQ==
dependencies:
mime-db "1.46.0"
mime-types@^2.1.16:
version "2.1.34"
resolved "https://registry.yarnpkg.com/mime-types/-/mime-types-2.1.34.tgz#5a712f9ec1503511a945803640fafe09d3793c24"
integrity sha512-6cP692WwGIs9XXdOO4++N+7qjqv0rqxxVvJ3VHPh/Sc9mVZcQP+ZGhkKiTvWMQRr2tbHkJP/Yn7Y0npb3ZBs4A==
dependencies:
mime-db "1.51.0"
mime-types@^2.1.30:
version "2.1.30"
resolved "https://registry.yarnpkg.com/mime-types/-/mime-types-2.1.30.tgz#6e7be8b4c479825f85ed6326695db73f9305d62d"
integrity sha512-crmjA4bLtR8m9qLpHvgxSChT+XoSlZi8J4n/aIdn3z92e/U47Z0V/yl+Wh9W046GgFVAmoNR/fmdbZYcSSIUeg==
dependencies:
mime-db "1.47.0"
mime-types@^2.1.31:
version "2.1.31"
resolved "https://registry.yarnpkg.com/mime-types/-/mime-types-2.1.31.tgz#a00d76b74317c61f9c2db2218b8e9f8e9c5c9e6b"
integrity sha512-XGZnNzm3QvgKxa8dpzyhFTHmpP3l5YNusmne07VUOXxou9CqUqYa/HBy124RqtVh/O2pECas/MOcsDgpilPOPg==
dependencies:
mime-db "1.48.0"
mime-types@^2.1.35, mime-types@~2.1.34:
version "2.1.35"
resolved "https://registry.yarnpkg.com/mime-types/-/mime-types-2.1.35.tgz#381a871b62a734450660ae3deee44813f70d959a"
integrity sha512-ZDY+bPm5zTTF+YpCrAU9nK0UgICYPT0QtT1NZWFv4s++TNkcgVaT0g6+4R2uI4MjQjzysHB1zxuWL50hzaeXiw==
dependencies:
mime-db "1.52.0"
nanoid@^2.1.0:
version "2.1.11"
resolved "https://registry.yarnpkg.com/nanoid/-/nanoid-2.1.11.tgz#ec24b8a758d591561531b4176a01e3ab4f0f0280"
integrity sha512-s/snB+WGm6uwi0WjsZdaVcuf3KJXlfGl2LcxgwkEwJF0D/BWzVWAZW/XY4bFaiR7s0Jk3FPvlnepg1H1b1UwlA==
nanoid@^3.1.20:
version "3.1.22"
resolved "https://registry.yarnpkg.com/nanoid/-/nanoid-3.1.22.tgz#b35f8fb7d151990a8aebd5aa5015c03cf726f844"
integrity sha512-/2ZUaJX2ANuLtTvqTlgqBQNJoQO398KyJgZloL0PZkC0dpysjncRUPsFe3DUPzz/y3h+u7C46np8RMuvF3jsSQ==
nanoid@^3.1.23:
version "3.1.23"
resolved "https://registry.yarnpkg.com/nanoid/-/nanoid-3.1.23.tgz#f744086ce7c2bc47ee0a8472574d5c78e4183a81"
integrity sha512-FiB0kzdP0FFVGDKlRLEQ1BgDzU87dy5NnzjeW9YZNt+/c3+q82EQDUwniSAUxp/F0gFNI1ZhKU1FqYsMuqZVnw==
nanoid@^3.1.30:
version "3.1.30"
resolved "https://registry.npmjs.org/nanoid/-/nanoid-3.1.30.tgz#63f93cc548d2a113dc5dfbc63bfa09e2b9b64362"
integrity sha512-zJpuPDwOv8D2zq2WRoMe1HsfZthVewpel9CAvTfc/2mBD1uUT/agc5f7GHGWXlYkFvi1mVxe4IjvP2HNrop7nQ==
nanoid@^3.3.1:
version "3.3.3"
resolved "https://registry.yarnpkg.com/nanoid/-/nanoid-3.3.3.tgz#fd8e8b7aa761fe807dba2d1b98fb7241bb724a25"
integrity sha512-p1sjXuopFs0xg+fPASzQ28agW1oHD7xDsd9Xkf3T15H3c/cifrFHVwrh74PdoklAPi+i7MdRsE47vm2r6JoB+w==
nanoid@^3.3.4:
version "3.3.4"
resolved "https://registry.yarnpkg.com/nanoid/-/nanoid-3.3.4.tgz#730b67e3cd09e2deacf03c027c81c9d9dbc5e8ab"
integrity sha512-MqBkQh/OHTS2egovRtLk45wEyNXwF+cokD+1YPf9u5VfJiRdAiRwB2froX5Co9Rh20xs4siNPm8naNotSD6RBw==So we are still getting incorrect versions installed which means I do not have faith that our server are going to work correctly (you can see some are off by major versions). What I want is to ensure that my servers are deployed using the exact versions that they are tested/compiled with down to the patch version.
meeroslav
commented
2 years ago @yharaskrik can you check which versions you have in node_modules? e.g. node_ modules/axios/package.json?
Despite what root package.json says, you are actually compiling with the hoisted version, unless it's a transitive dependency and not referenced directly in your project.
Can you perhaps create a repo with just package.json, lock file, and barebone project that I could use to reproduce this behavior?
meeroslav
commented
2 years ago @JoA-MoS unfortunately I can't access your nx-cloud run.
After running your steps locally that made it work, did the package-lock.json change? And if so, did you push it to CI? Which CI are you using? What machine/image you are using to run it on?
yharaskrik
commented
2 years ago Axios: "version": "0.27.2",
uuid "version": "8.3.2",
redis "version": "3.0.2",
nanoid "version": "3.1.22",
meeroslav
commented
2 years ago Thanks, then there might be a bug in version checking. Let me look at the source again.
meeroslav
commented
2 years ago Hmm... code looks fine. Is there some minimal repo where I can debug this?
JoA-MoS
commented
2 years ago @meeroslav
I was able to make the issue recur locally after updating axios to v 1.1.3. https://github.com/JoA-MoS/garage/pull/85
Root package.json
"axios": "^1.1.3",Generated package.json
"axios": "0.21.4",nxdeps.json
{
"source": "campsite-watcher",
"target": "npm:axios@0.21.4",
"type": "static"
},node_modules/axios/package.json
"version": "1.1.3",Is there a bug in how nxdeps.json is being generated?
JoA-MoS
commented
2 years ago I am actually looking at https://github.com/nrwl/nx/blob/master/packages/nx/src/project-graph/build-project-graph.spec.ts to see if I can add this test case but not that familiar with the code so I am getting oriented. Let me know if you have decided this is not the correct path.
JoA-MoS
commented
2 years ago @meeroslav - Here is a very simple repro library. I added the latest chalk 5.1.2 and would expect that to be included in the package.json when generated but the version is set to 2.4.2.
https://github.com/JoA-MoS/repro-nx-generate-package-json
pull the repo and run
npm ci
nx build exampleThen check dist/apps/example/package.json to see the chalk version
Current Behavior
npm ciof a a copied apps dist directory breaks after update to nx 15 because the root package-lock.json dependency version does not match the generated package.json dependency version.With nx 14 when using the
"executor": "@nrwl/node:webpack",with"generatePackageJson": truethe version of the dependency in the generated package.json matched the root package.json including the range.With nx 15 and the same config the the generated package.json dependency appears to be the evaluated exact version without the range.
before nx 15
after nx 15 update
Expected Behavior
the versions in the generated package.json should be exactly the same including range of the root package.json
Steps to Reproduce
Working Branch using nx 14 - https://github.com/JoA-MoS/garage/
Bad branch PR using nx 15 - https://github.com/JoA-MoS/garage/pull/81
Run build on both and compare generated package.json
Failure Logs
Environment