yarn list --depth=1 --json --production failed with code 1

[bebbi]

This is a (Bug Report / Feature Proposal)

Bug

Description

For bug reports:

• What went wrong?

When trying to yarn serverless package --stage=...,
the error is

yarn list --depth=1 --json --production failed with code 1

• What did you expect should have happened?

Do not call yarn listor --production as these are not supported by yarn berry.
For example here

• What was the config you used?
• What stacktrace or error message from your provider did you see?

Error: yarn list --depth=1 --json --production failed with code 1
    at ChildProcess.<anonymous> (/private/tmp/msm-api-new/node_modules/serverless-webpack/lib/utils.js:91:16)
    at ChildProcess.emit (node:events:513:28)
    at ChildProcess.emit (node:domain:489:12)
    at maybeClose (node:internal/child_process:1091:16)
    at Socket.<anonymous> (node:internal/child_process:449:11)
    at Socket.emit (node:events:513:28)
    at Socket.emit (node:domain:489:12)
    at Pipe.<anonymous> (node:net:322:12)

For feature proposals:

• What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
• If there is additional config how would it look

Similar or dependent issue(s):

• Support yarn 2 version #642

Additional Data

• Serverless-Webpack Version you're using:
  5.11.0
• Webpack version you're using:
  5.88.0
• Serverless Framework Version you're using:
  3.32.2
• Operating System:

but: yarn 3.4.1

• Stack Trace (if available):

[EhtashamAli]

same issue with npm

[vicary]

@bebbi PR is welcomed, you may take reference of #1252 and use the function isBerryVersion to give the correct args for yarn 2+ in getProdDependencies.

@EhtashamAli npm ls is backward compatible for many major versions, please further elaborate the situation in a new issue.

[bebbi]

Hi @vicary I've made a quick fix for myself which I'm happy to share but it kills yarn classic support.

In order to turn this change into a proper PR, I will need contributor support:

1. I hard-coded isBerry = true (which is the reason for some tests now failing). Is there a reason for sticking to long promise chains or could this repo move to async/await? Things are a bit hard to read.

2. I reverted this line introduced by PR Add yarn workspaces support #1258. I am not sure it is helpful for classic? For berry at least, it cleanly separates workspaces and with that addition, it seems you end up just listing the packages at the workspace root which are unrelated.

3. I contaminated packExternalModules with adding empty yarn lockfiles like const emptyLockFile = path.join(compositeModulePath, 'yarn.lock');. In a monorepo, yarn will refuse to install in a non-workspace path unless there is at least an empty lockfile.

4. I did a lot of manual work to make a clean code diff possible after I noticed I had prettier on which formatted a lot of code. I think this repo is in need of a prettier run in order to be able to evolve. Removing eslint rules about formatting would be helpful, and instead prettier auto-formatting with lint-staged/husky.

5. I had to add a noFrozenLockfile. From the way this works, I'm not sure you can achieve an immutable install in a monorepo esp. with stuff like transitive dependencies from monorepo deps. I haven't digged deep there.

6. I don't remember 100% whether this should work without serverless-plugin-monorepo, haven't tested without.

[vicary]

@bebbi Responding to your questions,

1. We are maintaining a long list of backward compatible features, think of it as a strength of this repo. Please use the original result of isBerry = await isBerryVersion() and only adds your changes in a new codepath (if), such that it covers both yarn v1 and v2+.
2. This should be an oversight between Detect yarn version to dynamically not add deprecated flags #1252 and Add yarn workspaces support #1258, I guess the correct way should be using the closest directory containing a package.json, counting upwards from cwd.
3. I think you almost hit it. If you are doing this in the temporary installation directory, and only does this when you detect a workspaces setting. Leaving all other cases (npm, yarn non-workspace... etc.) as-is.
4. We should already have eslint-prettier in place. Reformatting the whole project is alwasy kind of a meh for multiple reasons. It is usually done in a project level refactor (e.g. rewrite in TypeScript), I tried this approach in 2020 as an attempt to remove bluebird, but keeping all the tests green is a bit much for me.
5. Speaking with my experience in PNPM, lock file only references workspace versions. If you ensure an up to date lock file before bundling, our separated install should work. You may double confirm this in yarn.
6. There is no guarantee when combined with other build-time plugins, but PR is always welcomed if you are able to isolate issue about serverless-webpack.

Let's create a PR and start from there, I'll walk you through.

[brunopinhal]

any update about this?

[santosh279]

Any suggestions available for the above?
I am currently using node 18, nx 17 and serverless latest.

[j0k3r]

Feel free to provide a PR based on what @vicary explained. Otherwise it doesn't help to ask for an update or a workaround :)

[kennyhyun]

in my case

Environment: linux, node 18.20.2, framework 3.33.0 (local), plugin 6.2.3, SDK 4.3.2
Credentials: Local, "default" profile
Docs:        docs.serverless.com
Support:     forum.serverless.com
Bugs:        github.com/serverless/serverless/issues

Error:
Error: npm install failed with code 1
    at ChildProcess.<anonymous> (/home/user/Projects/aproject/node_modules/.pnpm/serverless-webpack@5.13.0_@types+node@20.11.17_serverless@3.33.0_typescript@3.9.10_webpack@4.46.0/node_modules/serverless-webpack/lib/utils.js:92:16)
    at ChildProcess.emit (node:events:517:28)
    at ChildProcess.emit (node:domain:489:12)
    at maybeClose (node:internal/child_process:1098:16)
    at ChildProcess._handle.onexit (node:internal/child_process:303:5)

2 deprecations found: run 'serverless doctor' for more details
error Command failed with exit code 1.

serverless-webpack/lib/utils.js does not log stdout and stderr, which make debugging difficult.
I manually edit the new SpawnError code in the utils.js to log the stdout