yarn list --depth=1 --json --production failed with code 1 about serverless-webpack HOT 8 OPEN

same issue with npm

from serverless-webpack.

any update about this?

from serverless-webpack.

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/[email protected]_@[email protected][email protected][email protected][email protected]/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

from serverless-webpack.

@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.

from serverless-webpack.

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.

from serverless-webpack.

@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.

from serverless-webpack.

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

from serverless-webpack.

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

from serverless-webpack.