SpikeMe
Documentation

Ecosystems

SpikeMe reads JavaScript/TypeScript, Python, and Go manifests today, curating top packages per category so your spikes are specific, with more ecosystems added by demand.

An ecosystem is a language plus its package registry: how SpikeMe reads your manifest and where it pulls live facts from. Each one is a small adapter, so the list grows by demand.

Supported today

SpikeMe supports three ecosystems today:

  • JavaScript/TypeScript via npm, read from package.json.
  • Python via PyPI, read from pyproject.toml or requirements.txt.
  • Go via Go modules, read from go.mod.

For example, a Python project points SpikeMe at its pyproject.toml:

[project]
dependencies = [
  "fastapi>=0.115",
  "sqlalchemy>=2.0",
  "pydantic>=2.9",
]

A Go project points at its go.mod, where SpikeMe reads the module, the Go version, and the require directives (those marked // indirect are transitive dependencies):

module github.com/acme/api

go 1.23

require (
	github.com/gin-gonic/gin v1.10.0
	gorm.io/gorm v1.25.12
	go.uber.org/zap v1.27.0
	golang.org/x/sys v0.28.0 // indirect
)

What SpikeMe understands

SpikeMe does not just read a flat list of names. It parses your runtime and dev dependencies and categorizes them:

  • npm: around 90 packages across categories like framework, meta-framework, state, data-fetching, testing, e2e, UI, and backend.
  • Python: around 55 packages across web framework, async/ASGI, ORM and database, validation, HTTP client, queues and tasks, data and ML, CLI, testing, and quality.
  • Go: curated packages across categories like web, database and ORM, CLI, config, logging, and testing.

From that categorized view it detects gaps: categories your stack has no package for. A project with a web framework but no testing library has a testing gap, and SpikeMe turns each gap into a suggested spike topic.

The real work behind this is curation. For each category SpikeMe tracks the top packages, so when it names candidates the document is specific to real, current options instead of generic advice.

Live facts by ecosystem

Each ecosystem knows where to collect the live facts that ground a spike. The sources are not symmetric, because each registry exposes different data:

  • npm: the npm registry (version, license), npm downloads (weekly downloads), and bundlephobia (gzipped bundle size).
  • Python: PyPI (version, license) and pypistats (weekly downloads).
  • Go: deps.dev (version, license).

Python has no bundle-size source, so a Python spike leans on version, license, and download numbers. Go exposes no public weekly-download count and no bundle size, so a Go spike is anchored on version and license — the missing downloads are expected, not a bug. See Generating spikes for how these facts are injected into the document.

Adding ecosystems

Under the hood, each ecosystem is a (manifest parser, facts source) adapter: one part that reads the manifest and categorizes dependencies, one part that collects live facts from the registry. Adding a new ecosystem means writing that pair and curating its top packages per category.

New ecosystems (Rust, Java, PHP, Ruby) are added by demand. On the home page you can pick an ecosystem to be notified when it opens, and the build order is pulled straight from that waitlist: the more demand an ecosystem gets, the sooner it ships.