problems with sample app plus basecoat install on wheels 4

[marshmob]

I have a working W3 app and I am trying to do a clean install at w4 with latest app and new basecoat.

I have a local development cf2025/IIS and trying to keep things simple (like me!)

I have downloaded W4 (2 files) and started it successfully (using working web.config from W3).

I assume you install basecoat first then the app but I cant get CLI to install basecoat successfully.

I don't run Lucee but I thought you don't need to as its baked into W4?

PS C:\inetpub\wwwroot\svgapp> wheels info
Wheels CLI v4.0.5

Project: C:/inetpub/wwwroot/svgapp
Wheels: v4.0.5
Engine: Lucee (LuCLI module)
Database: wheels
Server: running on port 8500

PS C:\inetpub\wwwroot\svgapp> wheels packages install wheels-basecoat
[INFO] Reading lucee.json...
[ERROR] ? Error reading lucee.json from .: lucee.json not found in .

Does anyone have a suggestion?

[wheels-bot]

Wheels Bot — Triage

Classified as other (general discussion / support / docs request).
No further bot action will be taken on this issue.

[bpamiri]

Hey — two things got tangled here.

wheels info reporting Engine: Lucee (LuCLI module) is the CLI itself. LuCLI is how the wheels binary runs; it is not your app server. IIS + Adobe 2025 is fine. You don't need Lucee for the app.

wheels packages install looks for a project file (lucee.json) so it knows this folder is a Wheels app. A zip drop of the two W4 files plus an old W3 web.config doesn't create that, so the command has nothing to read.

The path that works:

wheels new svgapp
cd svgapp
wheels packages install wheels-basecoat

Then point IIS at public/ (your W3 web.config can come along after). Don't install Basecoat first — scaffold the app, then add the package.

If you'd rather keep the folder you already started, I can paste a minimal lucee.json for the root. Want that?

[marshmob]

Thanks for your help

Following step-by-step instructions (https://guides.wheels.dev/v4-0-0/start-here/manual-installation/) generates a wheels application and I had thought that base template would have been enough.

after new app command, I needed to use "packages add" and not "packages install."

moved on to use sample https://github.com/wheels-dev/wheels-basecoat/tree/main/examples/showcase.

Copied files, added route and reloaded but:

Variable UIBADGE is undefined. --     The error occurred in C:/inetpub/wwwroot/svgapp/app/views/showcase/index.cfm: line 28

Looks like I have missed something (again)

Any ideas

[bpamiri]

Official command is wheels packages add (not install — that was my slip). Copy the showcase from vendor after add, not the raw GitHub tree. On Windows:

xcopy /E /I vendor\wheels-basecoat\assets\basecoat public\assets\basecoat
copy vendor\wheels-basecoat\examples\showcase\controllers\Showcase.cfc app\controllers\Showcase.cfc
xcopy /E /I vendor\wheels-basecoat\examples\showcase\views\showcase app\views\showcase

Route:

.get(name="basecoatShowcase", pattern="/basecoat-showcase", to="showcase##index")

Then wheels reload. /wheels/packages/wheels-basecoat is static admin docs — no mixins there.

[marshmob]

still getting the error.

http://localhost/wheels/packages shows

[bpamiri]

Thanks — the screenshot is the real story.

Basecoat never loaded. Adobe CF 2025 can’t compile vendor/wheels-basecoat/Basecoat.cfc because uiBoundCheckbox declares boolean switch = false. switch is reserved on Adobe, so you get that construct error and the package is marked failed. That’s why uiBadge is undefined — the mixins never made it into the view.

The HTMLEditFormat is undefined on /wheels/packages is a second bug, in Wheels’ own admin page, not your install.

Neither is something you can fix by recopying the showcase. We’ll get both patched. I’ll ping you when Basecoat compiles on Adobe 2025. Until then, skip the showcase — the rest of a wheels new app should still run.

[bpamiri]

Thanks — the screenshot was the real story.

Basecoat never loaded. Adobe CF 2025 can’t compile Basecoat.cfc when uiBoundCheckbox declares boolean switch = false (switch is reserved). That’s why uiBadge was undefined — the mixins never made it in.

That’s fixed in wheels-basecoat 3.0.1, which is on the registry now. Upgrade:

wheels packages add wheels-basecoat

or, if 3.0.0 is already in vendor:

wheels packages update wheels-basecoat --yes

Then recopy the showcase from vendor/ (not GitHub) so you pick up asSwitch, and keep the /basecoat-showcase route we already set.

wheels reload is not enough — PackageLoader only re-integrates on onApplicationStart. You’re on IIS + Adobe 2025, so recycle the app pool (or restart the ColdFusion 2025 instance). wheels stop / wheels start only bounce the LuCLI CLI server on :8500; it won’t restart IIS.

The /wheels/packages HTMLEditFormat error is a separate Wheels admin-page bug. That fix is on develop, not in 4.0.6 — it’ll ride a future 4.0.7 (or you can vendor-copy from develop if you want it sooner). It does not block the showcase once 3.0.1 is loaded.

Ping me if uiBadge is still undefined after the 3.0.1 recycle.

[marshmob]

oops! new error

[marshmob]

didnt get to try uiBadge

[bpamiri]

Thanks — and good news tucked in the bad: you’re past compile and into the showcase, so 3.0.1 cleared the switch reserved-word failure. Mixins are loading (the header uiBadge already ran). This next hit is another Adobe CF quirk, on the Slider & rating block.

Showcase uiSlider (Volume = 64) dies on this line in Basecoat:

numberFormat(local.pct, '0.##')

# is a Lucee-style NumberFormat digit. Adobe CF 2025 doesn’t accept it, so you get 0.# is an invalid mask for the input number: 64 and the page aborts on that Slider call — that’s why you didn’t get further into the block.

That’s on us in wheels-basecoat, not your install. We’ll ship a patch that uses an Adobe-safe mask (0.00) and ping you when it’s on the registry as 3.0.2. Until then you can either skip the Slider & rating block in the showcase view, or locally change that one mask in vendor/wheels-basecoat/Basecoat.cfc around line 1942 and recycle the app pool so PackageLoader re-integrates.