A dependency is a piece of outside code your workflow relies on: a package from npm, a library from Python's ecosystem, or a base image a step builds from. Almost any non-trivial step pulls in a few, and Tines 3B keeps track of them so you always know what third-party code is running across your automations.

When a step needs to do something it can't do with plain code, it reaches for an existing package. A step that talks to a database pulls in a database library; one that parses a spreadsheet pulls in a spreadsheet library. Those packages are the step's dependencies. They're the building blocks you didn't write, brought in so you don't have to reinvent them.

Tines 3B recognizes dependencies from the standard places each language keeps them:

The base image every Tines 3B step starts from doesn't count; dependencies are the things you add on top of it.

You add a dependency by listing it in the step's manifest file, the same way you would in any project: add the package to package.json or requirements.txt, and Tines 3B installs it when the step builds. You don't install packages by hand in the Dockerfile. Because builds are cached, a dependency is fetched and set up once and then reused on later runs, so declaring what you need keeps things both clear and fast.

Listing dependencies in the manifest also keeps them honest: the file is the single record of what the step depends on, rather than something buried in build commands.

You don't have to maintain a separate list of what your workflows depend on. Tines 3B reads the manifest files across your live workflows and builds that inventory automatically. Every package a step declares, and the version it's pinned to, is picked up and kept current as your workflows change. The result is an always-up-to-date picture of the outside code running in your account, without any bookkeeping on your part.

Tines 3B surfaces this inventory in a workflow dependencies view, which you can look at two ways:

The view also flags when the same package appears at more than one version across your workflows, which is a common source of subtle inconsistency worth knowing about.

Seeing your dependencies in one place turns a scattered detail into something you can actually manage. When a package has a known problem or a security advisory, you can tell immediately whether it's running anywhere and in which workflows. When you want to standardize on a version, the multi-version flag shows you where things have drifted. It's the supply-chain view of your automations: a clear answer to "what outside code are we running, and where?"