They used to have their own "youtube script interpreter" that was kind of fascinating.
But yeah as you said they switched to proper js runtimes recently.
What they don't need is hardcoding support for five JS package managers in their python files.
In the post the maintainer says that an older version of bun "results in the ejs lockfile being ignored".
The reason is that they never committed the necessary lockfile despite listing "support" for that bun version.
They have separate lockfiles for other package manager versions: bun.lock, deno.lock, package-lock.json, pnpm-lock.yaml.
This part of the comment is also interesting: "which is a significant security concern for users when considering all of the recent npm supply chain attacks".
If you would set up a proper build for the JS artifact instead of committing four lockfiles to your repository, users would not be as exposed to npm supply chain attacks.
They used to have their own "youtube script interpreter" that was kind of fascinating. But yeah as you said they switched to proper js runtimes recently.
What they don't need is hardcoding support for five JS package managers in their python files.
In the post the maintainer says that an older version of bun "results in the ejs lockfile being ignored".
The reason is that they never committed the necessary lockfile despite listing "support" for that bun version.
They have separate lockfiles for other package manager versions: bun.lock, deno.lock, package-lock.json, pnpm-lock.yaml.
This part of the comment is also interesting: "which is a significant security concern for users when considering all of the recent npm supply chain attacks".
If you would set up a proper build for the JS artifact instead of committing four lockfiles to your repository, users would not be as exposed to npm supply chain attacks.