Hi @dan
While working on my components I ran into something I wasn’t sure how to interpret, and I thought it was worth flagging in case it’s a real bug (or in case I’m missing something obvious).
What I noticed
When I run `rw-build properties`, I see output like:
[properties] Found 430 component directories
[properties] Processed 31 properties.config.json files
The 31 are exactly the native `com.realmacsoftware.*` components. My own `properties.config.json` files (under `space.rwpro.*`) never show up in the “processed” count, and no `properties.json` is generated for them. No warning or error either — they’re just silently skipped.
Looking at `build-properties.js:554` (v1.3.8), I noticed the glob pattern is:
```js
const pattern = path.join(packsDir, "**/*.elementsdevpack/components/com.**/**");
That com.** segment seems to match only folders starting with com., which would explain why my space.rwpro.smartbar isn’t picked up. I could be wrong about the interpretation, but that’s what it looked like from the output.
Temporary workaround
On my side I’ve patched the line locally (via patch-package, so it reapplies on npm install) to a more general pattern:
const pattern = path.join(packsDir, "**/*.elementsdevpack/components/*.*.*/**");
This still matches com.realmacsoftware.container like before, and also matches any reverse-DNS prefix with at least two dots — so my space.rwpro.* components get processed.
After the patch, rw-build properties processes my components correctly and generates the expected properties.json from my properties.config.json with the globalControl entries expanded.
Would you mind taking a look?
If this is actually a bug and the fix above makes sense, it would be great to have it addressed upstream so third-party devs with non-.com domains (.io, .dev, .space, etc.) don’t need to carry a local patch.
If instead I’ve misunderstood how the tool is supposed to work, please let me know the correct way to do this and I’ll update my setup.