JFrog Blog

> Does anyone have any other practices they can recommend for managing these type of projects?

Honestly, the only way around these sorts of issues is to utilize automation in some form.

I've found that setting up repositories (like devpi[0], Artifactory[1], or Docker Registry[2]) on a shared network location (for your project, could be local if you work alone) and using CI/CD tools (like Jenkins[3]) are the key. The goal is that you end up working on one portion of the code base at a time, and those need to go through the standard validation processes so that you can pull in the updated package version when you work on something down-stream. You making sure that the CI/CD environment _doesn't_ have access to other packages's non-versioned code is key for making sure things actually work as expected.

For example, if you have FooLib, and you need an update in that for BarApp, then even if you branch FooLib 1.2.3 to 1.2.3-1-gabc1234d (the `git describe` of the commit) on `feat/new-thingy` , then even if BarApp v2.3.4-1-gaf901234 depends on that new branch, it shouldn't be in any way able to reference that branch on the CI/CD build process. How do you get around this? Good development -- finish the FooLib branch, get that working, merge it in with the updated version, and push the package (with the new version) to the CI/CD-accessible repository. At that point, when you push your BarApp change, it can actually build and not die. But until FooLib has got a versioned update,…

Clickbait. At least propose what it is that you think needs to be done to address this so-called chaos.

Worth noting that ES2017 added String.prototype.padStart and String.prototype.padEnd. The whole left-pad thing is blown out of proportion.

Second, you shouldn't be relying on npm for deployments. You dig your own grave. If package deletion is a concern, then host a mirror with something like Nexus [0], or pay for a service [1] [2] to do it for you. Over the years there have been a few local npm mirror tools [3], but I don't think any of em have really caught much traction. There's also the option of bundling each release. For that you can use a tool such as Webpack [4], or take it one step further and generate a single binary using something like pkg [5].

Developers also have the option of forking their dependency graph and updating references in package.json. Sooner or later you'll start to find bugs in your dependencies and have to fix them. It's your responsibility, you own all that code. Don't be afraid of maintaining your own fork. If you find a critical issue you'll probably need to be able to deploy your update without depending on a third-party anyway. This is fairly common in other ecosystems. Heck, you can also just check in your node_modules folder into version control.

Don't get me wrong, npm certainly has its fair share of problems, and historically they haven't had the best defaults... But there's usually ways to work around the issues, and they're…

Someone asked "Would this have made sense for a company like GitLab if they didn't have the corporate backing of something like MS?" and deleted their comment while I was writing the answer below:

Being the canonical registry for a language (Rubygems) or technology (DockerHub) tends to be a huge expense.

The main expenses are cloud costs (bandwidth and storage) and security (defense and curation).

I've not seen examples of organizations turning this into a great business by itself. For example Rubygems is sponsored by RubyCentral http://rubycentral.org/ who organize the annual RubyConf and RailsConf software conferences.

Please note that running a non-canonical registry is a good business. JFrog does well with Artifactory https://jfrog.com/artifactory/ and we have the GitLab Package Registry https://docs.gitlab.com/ee/user/packages/ that includes a dependency proxy and we're working on a dependency firewall.

Ahh, i feel like this is probably the case for most of the corporation backed software out there - apparently offering just support isn't always a viable strategy to remain in business, so many out there lock bits of more advanced functionality behind pay walls: like many of the features of GitLab (https://about.gitlab.com/pricing/gitlab-com/feature-comparison/) and something like Artifactory (https://www.jfrog.com/confluence/display/JFROG/Artifactory+Comparison+Matrix)

I'm not sure whether that's a bad thing, though, since the alternative would be having no free plans/editions for those pieces of software at all, or maybe just using them for a few years and the company going bankrupt.

So that is the package caching proxy from the OpenAI/Huggingface fiasco!

However, many questions remain. JFrog positions itself as a vibe coding and AI security (!) company:

https://cybersecurityasia.net/jfrog-nvidia-secure-agentic-ai-development/

JFrog's own vibe code scanner failed:

https://jfrog.com/blog/jfrog-introduces-ai-generated-code-validation/

Given the feature explosion and chaos in the Artifactory cache, it is likely vibe coded and hence full of primitive security vulnerabilities.

JFrog is spinning this as an AI victory together with OpenAI. To the contrary, it is a hype and vibe coding failure.

But the AI bloggers will omit the vulnerability generation part.

After reading the underlying report (https://jfrog.com/blog/leaked-pypi-secret-token-revealed-in-binary-preventing-suppy-chain-attack/), I can't help but think: "where is the defense in depth?" Since `.pyc` files are just a cache of compilation that's already generally pretty quick, this could have been prevented by systems that simply didn't allow for pushing them into the Docker image in the first place. Or by having `PYTHONDONTWRITEBYTECODE=1` set on the developer's machine.

(Also, now I'm trying to wrap my head around the fact that there's such a thing as "Docker Hub" in the first place, and that people feel comfortable using it.)