Skip to content

Stabilize --preserve-order as a non-experimental CLI flag#217

Draft
vivainio wants to merge 1 commit intoCertainLach:masterfrom
vivainio:stabilize-preserve-order
Draft

Stabilize --preserve-order as a non-experimental CLI flag#217
vivainio wants to merge 1 commit intoCertainLach:masterfrom
vivainio:stabilize-preserve-order

Conversation

@vivainio
Copy link
Copy Markdown

Summary

  • Remove the exp-preserve-order compile-time feature gate across all crates
  • Make --preserve-order CLI flag and preserve_order parameter on std.manifest*/std.objectFields* always available
  • Add test coverage for preserve-order behavior

Implements #212

Details

The preserve_order functionality was already fully implemented behind the exp-preserve-order feature. This PR simply removes the #[cfg(feature = "exp-preserve-order")] gates from all 28 affected files, making the feature unconditionally available while keeping it opt-in (not enabled by default).

No behavioral changes — the same code that ran with --features exp-preserve-order now runs in all builds.

Test plan

  • cargo check passes
  • All workspace tests pass
  • std_param_names test updated for new parameter signatures
  • New preserve_order.jsonnet test covering: field ordering, objectFields/Values/KeysValues, manifestJson output, field override behavior, and object comprehension order

Remove the exp-preserve-order compile-time feature gate, making
--preserve-order and the preserve_order parameter on std.manifest*/
std.objectFields* always available without requiring a feature flag.

Closes CertainLach#212
@CertainLach
Copy link
Copy Markdown
Owner

I don't want to enable it by default unless the behavior is decided on cpp-jsonnet/go-jsonnet side

@vivainio
Copy link
Copy Markdown
Author

I don't want to enable it by default unless the behavior is decided on cpp-jsonnet/go-jsonnet side

It would be a flag that is disabled by default

@CertainLach
Copy link
Copy Markdown
Owner

I'm more concerned about preserve_order argument of stdlib functions

I'll think about it.

@vivainio
Copy link
Copy Markdown
Author

I agree that adding preserve_order to every stdlib function is not the right approach. I've opened an alternative PR #218 that makes --preserve-order a global-only CLI flag instead — no changes to stdlib function signatures at all. It uses a thread-local (same pattern as STACK_LIMIT) that all object iteration reads from automatically.

@vivainio vivainio marked this pull request as draft April 12, 2026 11:29
@CertainLach
Copy link
Copy Markdown
Owner

I agree that adding preserve_order to every stdlib function is not the right approach

This is the right approach, as having that as a global flag braks many usecases with internal manifestification, I only meant that preserve_order argument on stdlib functions should not be stabilized until consensus is reached with jsonnet upstream

@vivainio
Copy link
Copy Markdown
Author

Do you have a particular use case that would break in mind? Global flag is all-or-nothing, and without it everything would behave as before

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.

2 participants