search

serverless-heaven / serverless-webpack

Serverless plugin to bundle your lambdas with Webpack
MIT License
1.72k stars 414 forks source link

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

Open bebbi opened 1 year ago

bebbi commented 1 year ago

This is a (Bug Report / Feature Proposal)

Bug

Description

For bug reports:

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

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

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

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:

Similar or dependent issue(s):

Additional Data

but: yarn 3.4.1

EhtashamAli commented 1 year ago

same issue with npm

vicary commented 1 year ago

@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 commented 1 year ago

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 #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 commented 1 year ago

@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 #1252 and #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 commented 11 months ago

any update about this?

santosh279 commented 10 months ago

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

j0k3r commented 10 months ago

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 commented 3 months ago

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