Open Calvein opened 9 months ago
I'm kinda surprised this command is really missing. Or do I miss something?
+1 Any updates?
+1 Any updates?
I don't think it's implemented in v1.0.3 either. So no. No update. Maybe it will be part of any future roadmap?
+1 Any updates?
I don't think it's implemented in v1.0.3 either. So no. No update. Maybe it will be part of any future roadmap?
Uh I see, do you know of any temporary alternatives we could use until then? Ones that doesn't require a specific pm (I. E. Could be used with bun)
Uh I see, do you know of any temporary alternatives we could use until then? Ones that doesn't require a specific pm (I. E. Could be used with bun)
Not really.. but maybe try upgradeps:
bun install upgradeps
And then run (for the audit feature):
bunx upgradeps
Example output:
upgradeps v2.0.6 ─ run with -h to output usage information
✘ typescript 5.0.0 → 5.2.2 minor last publish 1 month ago
1 dependency 1 minor
+1
+1
+1
Anything here planned in the next time? Especially bun audit fix
would be great like npm audit fix
. The package-lock json is touched sometimes and i think the bun.lockb
should do as well.
Would love to see this added as well.
It would be great to have this feature in bun.
Ideally with features that are missing in other package managers, such as the ability to ignore certain security vulnerabilities for the time being by giving a reason (like implemented in npm-audit-resolver)
Trivy is a useful security scanning tool for polyglot projects. Rather than just running an npm audit
you can use Trivy to both audit your JavaScript modules, Dockerfiles, go modules, and more in a single-shot CLI fashion:
trivy fs /path/to/project # don't make me do stuff
I know it sucks but I found it easier to just stick with npm run audit
, of course it doesn't work without package-lock.json but you can generate this effectively with a flag (16 seconds on our Azure CI server) : npm i --package-lock-only
I know it sucks but I found it easier to just stick with
npm run audit
, of course it doesn't work without package-lock.json but you can generate this effectively with a flag (16 seconds on our Azure CI server) :npm i --package-lock-only
This sounds like a useful workaround in theory, but it has a huge issue: the package versions in a lockfile that npm
would generate at a given moment will not generally match the versions frozen in bun.lockb
. This can easily cause a false negative, which is bad for a security feature like this.
This workaround would get a lot more practical if bun
had a way to output bun.lockb
in package-lock.json
format. (I know bun bun.lockb
prints the contents, but certainly not in JSON format.) That might also make it more practical for GitHub to index bun.lockb
files and support it for Dependabot in the future.
I'm now in a situation where I maintain a repo that has "9 high severity vulnerabilities" but I can't properly audit or upgrade them using bun
.
I am fine with this for personal projects, but I'm worried this is borderline-untenable for anyone considering bun
for use at work. 😬
If bun
documented and supported a canonical way to run an npm
audit over a bun.lockb
in the near future, this would be a significant stopgap. As mentioned above, it could allow GitHub to integrate with Dependabot in the long-term, which would be a much better experience than finding out about vulnerabilities months too late.
And at least in the short-term it would be possible to set up a GitHub action to run such a check on a schedule in each individual repo for now.
If bun documented and supported a canonical way to run an npm audit over a bun.lockb in the near future, this would be a significant stopgap. As mentioned above, it could allow GitHub to integrate with Dependabot in the long-term, which would be a much better experience than finding out about vulnerabilities months too late.
If you run bun bun.lockb
, it will produce a yarn v1 yarn.lock
file. I wonder if there's a way to get npm audit
to run on that?
If bun documented and supported a canonical way to run an npm audit over a bun.lockb in the near future, this would be a significant stopgap. As mentioned above, it could allow GitHub to integrate with Dependabot in the long-term, which would be a much better experience than finding out about vulnerabilities months too late.
If you run
bun bun.lockb
, it will produce a yarn v1yarn.lock
file. I wonder if there's a way to getnpm audit
to run on that?
I believe yarn v1 does have an audit command: https://classic.yarnpkg.com/lang/en/docs/cli/audit/
If bun documented and supported a canonical way to run an npm audit over a bun.lockb in the near future, this would be a significant stopgap. As mentioned above, it could allow GitHub to integrate with Dependabot in the long-term, which would be a much better experience than finding out about vulnerabilities months too late.
If you run
bun bun.lockb
, it will produce a yarn v1yarn.lock
file. I wonder if there's a way to getnpm audit
to run on that?
Great suggestion!
I tested it, and it works: bun bun.lockb > yarn.lock && yarn audit
If bun documented and supported a canonical way to run an npm audit over a bun.lockb in the near future, this would be a significant stopgap. As mentioned above, it could allow GitHub to integrate with Dependabot in the long-term, which would be a much better experience than finding out about vulnerabilities months too late.
If you run
bun bun.lockb
, it will produce a yarn v1yarn.lock
file. I wonder if there's a way to getnpm audit
to run on that?Great suggestion! I tested it, and it works:
bun bun.lockb > yarn.lock && yarn audit
Ah, that's fantastic! 😄
I don't use yarn
, so I didn't realize bun bun.lockb
was outputting yarn
-compatible data!
I'm not a huge fan of having to use yarn
in addition to node
, npm
, and bun
, but it's certainly a very good stopgap until bun audit
exists!
EDIT: here's a little script I made to avoid writing yarn.lock
into repos:
#!/usr/bin/env bun
import { $, spawn } from "bun";
import { cp, mkdtemp, rm } from "node:fs/promises";
import { join } from "node:path";
import { exit } from "node:process";
const tempDir = await mkdtemp("/tmp/bun-audit-temp-");
let exitCode = 0;
try {
await cp("package.json", join(tempDir, "package.json"));
await $`bun bun.lockb > ${join(tempDir, "yarn.lock")}`;
exitCode = await spawn(["bun", "x", "yarn", "--cwd", tempDir, "audit"], {
stdout: "inherit",
}).exited;
} finally {
await rm(tempDir, { force: true, recursive: true });
}
exit(exitCode);
EDIT 2: Published as a package, so you can run: bun x bun-audit
Repo at: https://github.com/lgarron/bun-audit
EDIT 2: Published as a package, so you can run:
bun x bun-audit
Repo at: https://github.com/lgarron/bun-audit
I've been relying on this for a while, but it's kind of inadequate for addressing vulns.
The ip
package has a vulnerability and is unmaintained, which took a while for other projects to work around, e.g. https://github.com/modernweb-dev/web/issues/2747
npm audit fix
works if I switch my project to use a package-lock.json
file, but I can't figure out how to use bun update
to bump enough packages to avoid the vulnerable dep, even if I try to combine it with npx npm-check-updates -u
. 😕
A bun audit fix
command is critical for real-world projects that wish (or are legally required to) address vulnerabilities in a timely manner.
What is the problem this feature would solve?
I'm trying to replace node, yarn & jest with bun and the only missing feature to replace our workflow is an equivalent to
yarn audit
.What is the feature you are proposing to solve the problem?
Add
bun audit
which would work like npm/yarn audit.What alternatives have you considered?
I run
bun install
with the--yarn
flag to be able to runyarn audit