Portability Continues Into Data, Scripts, and CI

Hoppscotch's portability does not end when a request reaches the right network boundary. A collection must remain interpretable as its schema evolves, scripts must run without receiving unrestricted host power, and the same workflow must be usable in a headless CI process even though CI is not a browser or desktop session. This chapter follows those three extensions and shows what portability preserves, what it adapts, and where the current implementation draws explicit limits.

A multi-client ecosystem has a quiet failure mode: the request still exists, but its meaning drifts. An older collection may load with missing fields. A script may behave differently because a host API is unavailable. A CLI may claim to run a GraphQL collection but silently change operation semantics. The data, sandbox, and CLI layers matter because they make those differences visible and manageable rather than leaving each client to improvise.

Migration is part of the product contract

Hoppscotch's data package owns public structures such as collections, REST and GraphQL requests, environments, responses, cookies, validation, and migrations. The current source registers collections through version 12, REST requests through version 17, and GraphQL requests through version 10. Each version has a schema and an upward migration path. The collection translator can recursively migrate child folders and distinguish GraphQL-shaped requests from REST-shaped requests.

This is more than a maintenance convenience. A saved collection is a boundary between releases and clients. If the editor adds a script field, a request reference, or a response representation, the application must decide what an older artifact means when that field is absent. A migration can supply a safe default and preserve the rest of the artifact. Without that step, the same collection could be readable in one version and semantically incomplete in another.

The migration model also protects the difference between absence and invalidity. A known older version can be moved forward according to an explicit rule. A malformed or foreign object should not be “repaired” by guessing which fields look familiar. The presence of a migration supports compatibility within the supported model; it does not prove that every arbitrary JSON file can be recovered.

That distinction is important for team and CI use. A collection may be persisted by a backend, imported from a file, opened in the web application, and then consumed by the CLI. Those surfaces need a common interpretation of folders, requests, variables, auth, and scripts. The data package becomes a shared vocabulary for those transitions. It does not force the web and CLI to use identical transport code; it ensures they begin from a request meaning they can both recognize.

A migration therefore has a practical verification point. After an old artifact is translated, the current client should be able to validate it and expose the same user-level concepts. A default field is not just a value inserted to satisfy a type checker; it is a statement about how older intent maps to current behavior. That is why versioned schemas belong in the product architecture rather than only in release tooling.

Scripts need a host boundary

Scripts make a request workflow programmable. A pre-request script can derive values, change the request context, or prepare an environment. A post-request script can inspect the response and produce assertions or environment changes. But scripts are also user-provided code, and the host must decide what code can access.

The shared sandbox package provides web, Node, and scripting entry points.