Closed cryptodeal closed 2 years ago
The immediate cause is that as of #5551, errors during dependency tracing (adapter-vercel
uses @vercel/nft
to figure out which modules to include in the generated lambda) are thrown, rather than just printing gibberish to the terminal:
It didn't occur to me that this would break apps that were otherwise functional. With my degree from the University of Google I can tell you that ldd
is a utility found on Linux but not MacOS, which at least partly explains why it's building locally but not on Vercel, but I'm not qualified to actually fix it.
Going back to printing errors instead of throwing them would presumably fix this case, but it doesn't feel like the right long term solution. It feels like it might be a bug in nft
(presumably it shouldn't be trying to parse a binary file), so I think that's the place we should investigate.
Agree, would prefer to have best of both worlds in terms of the nicely cleaned up error logs & working builds; thanks for pointing me in the right direction! I've opened an issue in the @vercel/nft repo with the relevant info/links.
Going back to printing errors instead of throwing them would presumably fix this case
Yes that is the correct solution. The warnings from nft are not errors, they are warnings.
@styfle is it right that nft
is trying to parse /usr/bin/ldd
as a script? It does seem a bit odd just to disregard errors like this. Are there any warnings that are unsafe to ignore?
I think part of my confusion stemmed from the fact that the type of traced.warnings
is Error[]
, with stack traces pointing at nft internals. I wonder if they should just be objects?
is it right that nft is trying to parse /usr/bin/ldd as a script
Could be. I'm guessing something is attempting to read that file so nft trys to trace it. Which module is it coming from?
Are there any warnings that are unsafe to ignore?
I would argue all of them are safe to ignore. Imagine something like optionalDependencies
where the module checks for existence with try { require('some-pkg') } catch { }
. This will be traced by nft but might be missing and missing might be okay.
Thinking about this further: it makes sense that optional dependencies would result in a warning (that's what #5551 was about). But if nft
fails to parse a script, that feels like an error that should be treated as such — either the inputs are bad in a way that means the resulting app will likely suffer runtime failures, or nft
is treating something as an input that probably shouldn't be considered an input.
In both cases it's a readFileSync, which I wouldn't expect to result in nft attempting to parse the contents, but maybe it does that for a reason?
Yeah it is a bit strange now that I think about it. We should parse import
but probably not readFile
. However, removing the behavior causes several tests to fail https://github.com/vercel/nft/pull/304
Going to close this now that @vercel/nft@0.22
has been released — thanks @styfle!
@Rich-Harris We had to revert that change because it caused more bugs.
After further analysis, the real issue is that adatper is not setting the base
directory properly (looks like its effectively setting base: '/'
) instead of the user's working directory.
My build is failing....
Is there any workaround?
@Rich-Harris We had to revert that change because it caused more bugs.
After further analysis, the real issue is that adatper is not setting the
base
directory properly (looks like its effectively settingbase: '/'
) instead of the user's working directory.
@styfle Can you elaborate? base
isn't supposed to be the user's working directory, it's supposed to be the root directory — IIRC it was failing to trace stuff outside base
(e.g. in a workspace root, or in a linked package when testing locally), so we have to be able to guarantee that every file is inside base
. We then find the common ancestor:
I think we have to pin 0.22.0 until we can find an alternative approach, since 0.22.1 is causing build failures.
@Rich-Harris The base
should be the monorepo root.
You can use repoRootPath
provided to the Builder/Runtime to detect this like so:
Otherwise, you could try to detect workspaces the same way yarn/npm/pnpm does to find the monorepo root.
Describe the bug
Using @sveltejs/adapter-vercel@1.0.0-next.63, I can build a pnpm monorepo (using turborepo) locally, but deployment to Vercel fails with a cryptic error:
Same portion of logs when building locally:
The same project w/o any changes, but using pinned version @sveltejs/adapter-vercel@1.0.0-next.62 deploys successfully (without the nice cleaned up build output ://).
I've linked a reproduction which has version @sveltejs/adapter-vercel@1.0.0-next.63 and build fails. Additionally, I've copied the log files from the failed build on Vercel using 1.0.0-next.63 in it's entirety.
I've also previously deployed a version to Vercel in the same repo using 1.0.0-next.62 (no other file changes), which built/deployed to Vercel without issue; the build logs for this working deployment using 1.0.0-next.62 can be found here.
Reproduction
https://github.com/cryptodeal/adapter-vercel-build-error
Logs
System Info
Severity
blocking an upgrade
Additional Information
Using SvelteKit in BallerAnalytics, a basketball analytics/fantasy insight platform, this blocks an upgrade.
Have worked around by pinning @sveltejs/adapter-vercel@1.0.0-next.62 for the time being, but ultimately will prevent upgrading to latest version of adapter Vercel.
Additionally, Googling
vercel "usr/bin/ldd"
produces only 2 results, one of which references @napi-rs, which is one of the dependencies listed in the errors that were displayed prior to the update released in version 1.0.0-next.63.