GeezerVison

An app currently has no way to override a build setting that a plugin declares, and no way to find out that it failed to.

The app's xcconfig never wins

XcconfigService.mergeFiles keeps whichever value is already in the destination and deletes the incoming one:

userConfig.attributes.each do |key,|
  existingConfig.attributes.delete(key) if (userConfig.attributes.key?(key) && existingConfig.attributes.key?(key))
end
userConfig.merge(existingConfig)

First writer wins — and mergeProjectXcconfigFiles merged every plugin's platforms/ios/build.xcconfig before the app's App_Resources/iOS/build.xcconfig. So for any key a plugin set, the app's value was discarded outright. Not "sometimes lost": never applied. Among plugins the winner was whichever came first in dependency-resolution order, which nobody controls.

This PR merges the app's file first. Plugins still supply every key the app says nothing about; they just stop overriding the ones it does.

Where this bites today: V8 14.9 (NativeScript iOS 9) made v8config.h reject C++17 outright —

#if __cplusplus <= 201703L
#error "C++20 or later required."
#endif

— while several plugins pin CLANG_CXX_LANGUAGE_STANDARD = c++17, which sat exactly on the old floor. One stale transitive plugin holds the whole app below the floor, and the app cannot lift it. The resulting error points at the runtime's headers rather than at the plugin that pinned the standard.

Discarded settings are now reported

The merge dropped keys in silence, so a discarded setting was indistinguishable from one that was never written. That's the reason the case above is hard to diagnose: nothing tells you which plugin pinned the value, and the failure surfaces somewhere else entirely.

mergeFiles now reports what it dropped:

Ignoring CLANG_CXX_LANGUAGE_STANDARD = c++17 from node_modules/some-plugin/platforms/ios/build.xcconfig:
already set to c++20 by a higher precedence xcconfig. The app's App_Resources xcconfig wins over any plugin's.

Only conflicts whose values genuinely differ are reported — two files agreeing on a key is not worth a warning, and that keeps this quiet on normal projects. Reporting is also fully isolated from the merge: an unparseable result is traced and ignored, never thrown.

Compatibility

The precedence change is behavioural. An app that sets a key a plugin also sets now gets its own value where it previously got the plugin's. That is the intent, but it can surface a latent misconfiguration — a value set long ago that silently never applied and now does. The new warning makes those visible rather than mysterious.

Conflicts between plugins are unchanged: still resolved by dependency order, still arbitrary. xcconfig can't express "highest wins" for an ordered value like a language standard, so warning is the practical ceiling; this PR at least makes them audible.

Tests

npm test — 1514 passing, 9 pending, 0 failures.

Added The app's build.xcconfig wins over a plugin's, which sets CLANG_CXX_LANGUAGE_STANDARD in both an app and a plugin xcconfig and asserts the app's value survives while a plugin-only key still lands. It runs the real xcodeproj merge rather than a stub, so it also covers the modified Ruby.

test/xcconfig-service.ts gains a logger registration for the new dependency.

Summary by CodeRabbit

• Bug Fixes

  • Updated iOS xcconfig merging so app App_Resources settings are authoritative over plugin-provided values when conflicts occur.
  • Added warnings for detected xcconfig key conflicts, while continuing to preserve the higher-priority (app) values.

• Tests

  • Added a merge test covering precedence for conflicting CLANG_CXX_LANGUAGE_STANDARD, ensuring app-pinned values win while unrelated plugin settings (e.g., GCC_C_LANGUAGE_STANDARD) are retained.