[jwrosewell]

Problem

Eleven of the examples' 51d.json files name an engine by a path into this repository's source, such as "../../../deviceDetectionCloud" in device-detection/fiftyone.devicedetection.cloud/examples/cloud/gettingstarted-console/51d.json at fe81e018. Such a file only works beside the source. ci/install-package.ps1 lines 43 to 55 rewrites two of them so the Publish tests run them against the packed packages, and device-detection/run_examples.md lines 72 to 92 and ip-intelligence/run_examples.md lines 61 to 81 tell a person running an example against the published packages to edit the rest by hand. This is gap DX-node-20, left under "What remains" in #95, which named the mixed web example's engine by package.

PipelineBuilder.buildFromConfiguration requires each elementName from the core package (pipeline/fiftyone.pipeline.core/pipelineBuilder.js lines 143 to 150), so a package name, such as fiftyone.devicedetection.cloud/deviceDetectionCloud, resolves both in this repository, where npm workspaces link the packages, and in an application that installed them.

What the specification says

device-detection-specification/required-examples.md lines 20 to 23 at c8128ca4 asks for each example to be run "as someone would run it from a fresh clone", and the examples rule asks that each also builds and runs against the published packages, which a path into the source cannot.

What changed

1. The eleven files name their engines by package, fiftyone.devicedetection.cloud/deviceDetectionCloud, fiftyone.devicedetection.cloud/hardwareProfileCloudEngine, fiftyone.devicedetection.onpremise/deviceDetectionOnPremise, fiftyone.ipintelligence.cloud/ipIntelligenceCloud, fiftyone.ipintelligence.onpremise/ipIntelligenceOnPremise and fiftyone.pipeline.engines.fiftyone/shareUsage.
2. ci/install-package.ps1 no longer rewrites two of them, as the files now work against the installed packages as they are.
3. Both run_examples.md files say the files work unchanged with the installed packages, in place of the steps to edit them.

The helpers that make a relative name absolute, such as OptionsExtension.updateElementPath, act only on a name that starts with ., so they leave these names alone.

Tests

ci/tests/exampleConfigurations.test.js reads every 51d.json under the four product folders and checks that each element is named by package and resolves from the core package, as PipelineBuilder requires it.

• Red, run 43568050346, on the test commit c6f2965, where 11 of 29 failed on Ubuntu and on Windows, one for each relative name.
• Green, run 43568101979 at 1f96238, where 29 of 29 passed on both.

Both ran in a throwaway workflow that is not part of this draft. The examples' own tests run each of these files in the full build below.

Full build

Run 43569113470 on tmp/pr-matrix-110, started by tools/pr-matrix.py without macOS. All 7 Setting 'PullRequestSha' lines give this head, 1f96238, and Configure printed "Left out 2 macOS entries". Each of the six Build and Test jobs, Ubuntu, Ubuntu ARM and Windows on Node.js 22 and 24, passed 1,412 unit tests with 2 skipped and 133 integration tests with 4 skipped, among them the new configuration test and the tests of the examples that read these files, on Windows as well as Linux.

macOS was left out of this draft's full build under the 9 November decision. The rc head is built with macOS before it merges into main.

What remains

The Publish workflow's test of the published packages runs the two web examples that ci/install-package.ps1 used to rewrite, and now runs them on these files as they are. That is next shown by the Publish dry run of the release head.