Skip to content

Artefact / Artifact

Artifacts serve as outputs of the development process. In context of Javascript these are the bundled and minified .app.js files within a dist/ folder, the .tgz tarball produced when you run npm run pack. A package can be an artifact, but not all packages are artifacts since there are also libraries, extensions, tools that can be packaged, but might require a totally different way to use and distribute.

Ecosystem

The world of tools, libraries, and conventions that has grown up around a programming language. The JavaScript ecosystem, for example, includes frameworks, package managers, lint and build tools, monorepo setups, editor extensions, and the conventions everyone loosely follows. When you pick a language to ship an app in, you’re also joining its ecosystem — the collection of libraries and tools that make creating and shipping apps easier.

Library

Code written to be used by other code, not to be run on its own. Libraries are intended for reuse across different codebases. They are focused sets of code that concentrate functionality and convention, so other developers can leverage the same functionality.

Mirror

A read-only copy of a registry. A mirror stays in sync with an upstream registry and serves the same packages, often from a server closer to you (or behind your company firewall). You use it the same way you’d use the original registry; you just can’t publish new packages to it.

Module

A unit of code inside a language’s import/export system — the thing you import from or export functionality from. People sometimes use “module” to mean the same thing as “package,” and sometimes to mean a smaller piece inside a package. Because the word gets used two ways, you usually need a little context to know which one someone means.

Package

An artifact that contains code, and metadata for resolving dependencies and running its scripts effectively.

Artifacts are often made to be shared and reused by other developers, but can also play a role in audit and traceability. Packages are what you publish to a registry and what you install into a project. If you’ve ever run npm install react, you installed a package!

Package Metadata

The data about a piece of software, collocated with its code. For a Javascript package it’s most prominently the manifest, package.json and package-lock.json. It’s the label on the tin: it tells tools and humans what’s inside before anyone opens it.

Project

Software defined by what it’s trying to do, not by whether parts of it get reused. An app or service you ship to users is a project. It might depend on a pile of packages, or vendor in some code, or in rare cases pull in nothing at all — what makes it a project is its goal.

Registry

A server (or service) that hosts packages and lets you publish and download them. Most languages have several prominent public registries where open source developers share code. For JavaScript that’s the npm registry — and many teams also run private registries inside their company. When your package manager “goes to fetch” something, the registry is where it goes.

Version

The label pinned to a specific release of some software, usually found in its metadata. Most ecosystems use semantic versioning (major.minor.patch, like 2.1.3) to indicate how much changed and whether you should expect breaking differences. How strictly that’s enforced varies a lot between languages, but the version is always what tells you which release of a package you’re getting.

  • Major (e.g. 3.0.0): breaking changes — updating may require code changes in your project.
  • Minor (e.g. 2.1.0): new features added in a backwards-compatible way.
  • Patch (e.g. 2.1.3): backwards-compatible bug fixes or small tweaks.