Racket 8.0: Avoiding Accidental Public Exposure via provide (all-defined-out)

Quick Answer

Racket 8.0 does not emit a compile‑time warning when a module re‑exports an identifier that was not originally exported. The safest approach is to stop using (provide (all-defined-out)) in production libraries and replace it with an explicit export list or a small helper module that keeps internal helpers truly private.

Why the Change Matters

• In 7.0 (only-in mod id) could import any top‑level binding, even if it was never provided.
• 8.0 enforces that only-in may only reference identifiers that mod has explicitly exported.
• Using (provide (all-defined-out)) lifts all top‑level definitions into the public API, exposing helpers that might change or be removed later.

Recommended Mitigations

1. Explicit Export Lists

(provide foo bar baz)

• Only the listed identifiers become part of the module’s public surface.
• Any helper or internal helper not on the list remains invisible to downstream imports.

2. Internal Helper Modules

;; helpers.rkt
(define (helper-a x) ...)
(define (helper-b y) ...)

;; main.rkt
(require "helpers.rkt")
(provide foo bar) ; only re‑export the public API

• Keeping helpers in a dedicated module isolates them from the public API.
• Downstream modules can import helpers.rkt only if they truly need the internals.

3. Linting & Static Analysis

• Use racket-lint or racket-verify to scan for (provide (all-defined-out)) in your codebase.
• Write a custom lint rule that emits a warning when (provide (all-defined-out)) appears in a library module.
• Integrate the rule into CI to catch accidental re‑exports early.

4. Manual Auditing of only-in Uses

After upgrading to 8.0, run a quick grep to find any (only-in that references a module that no longer provides the imported identifier. Example:

grep -R "(only-in" -n . | grep -v "provide" | grep -v "#lang"

Any remaining matches indicate imports that will now fail. Update them to use the new exported names or remove the import.

When to Ask for More Information

If you still rely on (provide (all-defined-out)) in a library that is consumed by other projects, I’d like to know:

• Do you have a list of modules that currently use (only-in) to import non‑exported identifiers?
• Are there any helper functions that you would prefer to keep private but are currently exposed?

Answering these questions will help tailor a migration plan that preserves your API contract while keeping internals hidden.