Change:
A clear and concise description of what the bug is. Grep confirms the dep is preset in both lock files but not in . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Does the issue go away if you delete and regen the lockfile yourself? It looks like while the top-level dep does have and fields, the workspace package dep on from does not
If that fixes it, I should probably review and maybe merge so we can get a warning that more explicitly says to go check if npm did an oopsy and generated a busted lockfile yet again that the upstream project committed I eventually do have an idea that will allow that stuff to work with supplied FOD hashes despite npm's madness, but I still need to refactor a good bit of code for that to be implemented
So I tried regenerating the lock files using but it attempts and fails to build the entire project when I do that? Wtf? Anyhow, I tried the master branch where I can rebuild the lockfile and this is the error now:
You have to also add (yay npm...) I'll see if I can fiddle with it and figure out what's wrong today
Thanks. Updated the lockfile and injected it into the source and now I get the next unfetched dep:
I'm having trouble reproducing this myself with a freshly generated lockfile. Can you share your lockfile? (Also just in case, you do have to make sure to delete the existing as well as all directories before will finally produce a proper lockfile again. Npm upstream has no interest in fixing that keep-broken-lockfiles-broken-at-all-costs behavior because they do not care about reproducibility I guess )
Also since this uses , you need and as well for it to build. It looks like their install scripts do something funky though so you might need to add a hook or make your own if you can't patch their to fix it
Oof actually the "funkiness" is our parsing with balking at the scripts being run at all and being output to stdout prior to the actual JSON output I'm surprised that hasn't come up until now, but I'll have to see if I can fix that in our install hook...
It looks like does work, so I guess we'll just have to do that and will lose the logging for those scripts to derivation output I may bug upstream to make that output go to stderr when is specified too, but I won't expect much (side note but does not actually work and despite it being documented that it should be ignoring scripts, the fact that it does not is considered "working as intended" according to upstream PRs I'm finding, so )
Fix for the above issue is in . If you do the above stuff and add a to wrap a bin since they don't specify one in the top-level (or you can try to set and maybe it'll automagically find it, but I'll let you test that) then your appium package should work with now
I lost motivation in packaging appium as node isn't my forte and it would have been more of a drive-by contribution anyways and that's probably not good enough for such a project. I just wanted to report that buildNpmPackage failed me here because this bug could very well affect other packages too. If you don't feel like this can be reasonably fixed on our side, feel free to close this.
Yep, understood, thank you for the report! I greatly appreciate these quality reports for issues to fix and reduce friction with npm packages The above PR should fix the immediate issue with this package (aside from the upstream lockfile being busted and needing to be replaced...). I just happened to notice it didn't install bins, but that's not an issue on our end The rest is mostly up to documenting quirks, like that having sharp as a dependency means the derivation needs pkg-config and vips
Is it alright if I mark as closing this issue? Technically the initial issue reported is due to a busted upstream lockfile (I wonder if would fix it...), but the only other thing preventing appium from being packagable is and the lockfile is an upstream issue that would need to be fixed there
Sure.
I have a related issue — a package that doesn't show up in the lockfile at all is being installed, causing an ENOTCACHED error. <details<summaryerror logs</summary</detailsNotably, env-paths doesn't show up in the package- file at all. <details<summarypackage-</summary</details
Ah — nevermind, it's because env-paths shows up in the associated file and there's a mismatch between that and the package- file. I thought the package- was the source of truth. False alarm.

Discussion:
local dest="$packageOut/$(dirname "$file")" mkdir -p "$dest" cp "${npmWorkspace-.}/$file" "$dest" <del> done < <(@jq@ --raw-output '.[0].files | map(.path) | join("n")' <<< "$(npm pack --json --dry-run ${npmWorkspace+--workspace=$npmWorkspace} $npmPackFlags "${npmPackFlagsArray[@]}" $npmFlags "${npmFlagsArray[@]}")") </del> <ins> done < <(@jq@ --raw-output '.[0].files | map(.path) | join("n")' <<< "$(npm pack --json --dry-run --loglevel=warn --no-foreground-scripts ${npmWorkspace+--workspace=$npmWorkspace} $npmPackFlags "${npmPackFlagsArray[@]}" $npmFlags "${npmFlagsArray[@]}")") </ins> while IFS=" " read -ra bin; do mkdir -p "$out/bin"