Skip to content

Conversation

@joevin-slq-docto
Copy link
Contributor

@joevin-slq-docto joevin-slq-docto commented Dec 5, 2025

Summary

Fixes job execution order when using extends in remote configurations. Jobs from the base configuration now execute before jobs from the extending configuration, preserving dependency chains.

Closes #1218

Problem

When a remote config uses extends to load another config, the job execution order was reversed:

  • Jobs from the extending file executed first
  • Jobs from the base file executed last

This broke dependency chains. For example, if a base config sets up dependencies (like mise install) and an extending config adds additional checks (like prettier), the checks would run before dependencies were installed.

Root Cause

The mergeJobsSlice function in internal/config/load.go processed jobs in the wrong order:

  1. It added dest (existing/extending config) jobs first
  2. Then added src (new/base config) jobs

This order worked for local overrides but was incorrect for extends, where the base should come first.

Solution

This PR restructures mergeJobsSlice to establish a clear semantic convention:

  • src = base configuration (should execute first)
  • dest = override/extension (should execute second)

Changes made:

  1. Refactored mergeJobsSlice (internal/config/load.go:510-595):

    • Now processes src jobs first, then dest jobs
    • Updated merge logic for jobs with matching names
    • Adjusted {cmd} template replacement to work with the new order
  2. Updated addHook call (internal/config/load.go:373):

    • Swapped parameter order to maintain semantic consistency
    • Main config (base) is now passed as src, local override as dest

Testing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Job order is reversed when using extends in remote configs

1 participant