Correct json syntax for module settings

[carehart]

Using the provided example was getting a compile error on startup of bx when using this module.

The json offered here (such as to be put in boxlang.json) is not syntactically correct, in that it uses name = val for most settings, when instead it should be "name" : val.

It looks like someone copied it from the settings code offered at the TOP of the page...but that's for use in ModuleConfig.bx, wihch is code rather than json...but they'd corrected only the "engine" setting and left the others unchanged, thus this error.

Type of change

Please delete options that are not relevant.

• Bug Fix
• Improvement
• New Feature
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ x] This change requires a documentation update

[carehart]

As a follow-up to my first comment, I want to note as well that the code offered there in the TOP section is also no longer in sync with what comes out of the box in the ModuleConfig.bx (as found in \BoxLang\modules\bx-compat-cfml\ installed yesterday).

There are several more lines in the code that are not reflected here, but it's not as important as this json as the code seems more for documentation than actual use (whereas the boxlang.json has zero modules installed, and we DO need to rely on this page for clarification of what to put in there).

Anyway, I didn't want to presume to propose changing the "code" section at the top, as I didn't know the purpose for it being there, and whether the author may have preferred to not yet sync that with the actual code in the .bx file.

[bdw429s]

@lmajano Can you review this pull?

[carehart]

Hi, guys. I got notified of the acceptance/merge of the PR. Thanks. But the doc page itself remains unchanged: https://www.forgebox.io/view/bx-compat-cfml

I do appreciate that it may simply take time to work it's way to the site, but I ask because I got an email reporting, "[ortus-boxlang/bx-compat-cfml] PR run failed at startup: Pull
Requests, Attempt #2 - Correct json syntax for module settings (90546bb)". I don't find more detail in the link for the workflow that was offered with the email.

Is this perhaps some common challenge and it just may take some more time before the forgevix page reflects the change? (FWIW, I did clear cache in my browser, so that's not the issue.)

[lmajano]

The update happens on a new release. Not on snapshots. Luis Majano CEO Ortus Solutions, Corp 1-888-557-8057 909-248-3408 www.ortussolutions.com www.boxlang.io www.luismajano.com Support Open Source: www.patreon.com/ortussolutions Linked In: https://www.linkedin.com/pub/3/731/483 Social: twitter.com/ortussolutions | twitter.com/lmajano | bsky.app/profile/lmajano.bsky.social El 13 ene 2025, 15:34 +0100, Charlie Arehart ***@***.***>, escribió:

…

Hi, guys. I got notified of the acceptance/merge of the PR. Thanks. But the doc page itself remains unchanged: https://www.forgebox.io/view/bx-compat-cfml I do appreciate that it may simply take time to work it's way to the site, but I ask because I got an email reporting, "[ortus-boxlang/bx-compat-cfml] PR run failed at startup: Pull Requests, Attempt #2 - Correct json syntax for module settings (90546bb)". I don't find more detail in the link for the workflow that was offered with the email. Is this perhaps some common challenge and it just may take some more time before the forgevix page reflects the change? (FWIW, I did clear cache in my browser, so that's not the issue.) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[bdw429s]

What Luis said is half true :) Your change DID publish to ForgeBox and IS visible here
https://www.forgebox.io/view/bx-compat-cfml/version/1.17.0-snapshot
Note, ForgeBox archives the description for each version individually, so you can go back in time and see what the description was for a given package at a given version. So, the build did run and published a new 1.17.0-snapshot version which has your updated description. The reason you don't see it when you visit the page https://www.forgebox.io/view/bx-compat-cfml/ is because that page is showing the latest stable stable version of 1.16.0+22 by default! And the version 1.16.0 has the old description.
ForgeBox always defaults to the latest stable version (unless all versions are pre-releases) So, what Luis meant was when we publish a major version next, you'll see your new description on the default forgebox homepage for that package.

[carehart]

Ah, thanks for that elaboration. We on the outside might way not as readily connect those dots, or perhaps it’s we who are not using Forgebox often. OK, maybe it’s just we who are not living in the world of frequently released software. :-) And I guess it’s a bit of a bummer if the change to a description HAS to be tied to a release….but I’m sure you have your reasons, or it’s just infrequent that it’s an issue. Again, thanks to you both. As always, just trying to help—and in this case trying to help those a) not installing bx via commandbox and/or b) not installing the cfml-compat using the cli (Or that seems to be why I hit this. It’s been a couple of weeks since I ran into this. Just sharing context.)

[bdw429s]

And I guess it’s a bit of a bummer if the change to a description HAS to be tied to a release

That's because it makes sense in most cases :) Usually descriptions include installation directions, usage direction, and docs which are tied to the features in that specific release. Consider if we added a new feature to a snapshot release and updated the documentation in the readme to match. We wouldn't want those new docs to be "live" on the default forgebox page prior to that feature actually being released as the default stable version! That would create even more confusion. Furthermore, if you're someone using an older version of a module, you can always navigate to the description that corresponds with that version, so you can be sure you're not reading docs that don't apply to your version.

Luis could also merge your commit into the master branch as well, and re-run the stable build, or just run a local publish command. In this case, we cut new versions of these modules on a regular basis with our weekly betas, so it will just be a matter of days before another compat release is cut and the issue resolves itself.

[carehart]

Thanks, though that's why I put emphasis on "HAS to be" in sync. :-)  I do certainly understand that USUALLY the description would be in lockstep with the code for that version. And this situation may be too unusual to warrant extra efforts. Was just putting the thought out there. :-)