`prismic push` and `prismic pull` write JSON in different key orders, causing perpetual cosmetic drift

[angeloashmore]

Summary

The CLI writes local model JSON in a different key order than what pull retrieves from the API. After a successful push, prismic status reports all pushed types and slices as "Differ" indefinitely until the user runs prismic pull --force and commits the canonicalized result. The diff is purely key-ordering — no schema or value changes.

This creates confusing UX: users see persistent drift after a green push and don't know whether something actually failed.

Environment

• prismic CLI: 1.7.0
• Node: v24.13.1
• OS: Linux (also reproducible on macOS)

Reproduction

In a fresh project:

1. npx prismic type create "Announcement"
2. npx prismic field add uid --to-type announcement
3. npx prismic field add text message --to-type announcement --label "Message"
4. npx prismic field add link link --to-type announcement --allow-target-blank --allow-text --label "Link"
5. git add . && git commit -m "add announcement type"
6. npx prismic push → "Pushed 1 type(s)."
7. npx prismic status → reports announcement (custom type) under "Differ"
8. npx prismic pull --force → updates local file
9. git diff customtypes/announcement/index.json → only key reordering

Actual diff produced by step 9

diff --git a/customtypes/announcement/index.json b/customtypes/announcement/index.json
@@ -2,8 +2,6 @@
   "id": "announcement",
   "label": "Announcement",
   "repeatable": true,
-  "status": true,
-  "format": "custom",
   "json": {
     ...
-  }
+  },
+  "status": true,
+  "format": "custom"
 }

For slices, the drift includes ordering of name/type and imageUrl/docURL per variation:

 {
   "id": "hero",
-  "name": "Hero",
   "type": "SharedSlice",
+  "name": "Hero",
   "variations": [
     {
       "id": "default",
       "name": "Centered Light",
       "description": "Default",
-      "docURL": "",
       "imageUrl": "",
+      "docURL": "",
       ...

Expected behavior

After prismic push, prismic status should report "Already up to date." Either:

• push writes local files in the API's canonical key order (matches what pull would produce), or
• status does an order-insensitive comparison

Actual behavior

status reports drift forever until the user runs pull --force and commits the result. With the git-clean safety check on push, this also blocks subsequent pushes until the cosmetic diff is committed — adding noise to the git history.

Impact

• Confusing for new users, who can't tell if their push silently failed.
• Adds purely-cosmetic commits to project history.
• Combined with the git-clean safety check on push, increases friction in iterative model work.