[Commandbox 5.9.0] What is the Right Way to Start Development Servers When Using the Ortus Module Template?

Communities CommandBox CLI
1

I am building a new module using the official Ortus module-template as a starting place. I like that the template has almost everything scaffolded for developers, but I am a little unclear on the best way to use it when it comes to starting the server while building the app.

I see there are several preconfigured server.json files in the root of the project:
image

Each server config maps the web root to the “test-harness” folder like this:

"aliases":{
    "/moduleroot/login":"../"
}

I can start the Lucee server by typing this into Commandbox:

server start server-lucee@5.json

The server starts as expected, but then Commandbox doesn’t show me that the server is running in the bullet train, nor can I get the status by typing server status anymore. Because I used a custom config file, I need to use server status server-lucee@5.json. While this works, it’s a lot more typing.

The second issue I have run into is that if I’m building a Coldbox module, I can no longer call fwreinit or coldbox watch-reinit because Commandbox doesn’t know where the web root is.

The shortcut workaround I’ve been using is to create a server.json file inside of the test-harness folder and use that as the root of my development server. The server.json looks like this:

{
    "name":"my-awesome-module",  <--- whatever you want to call the server
    "app":{
        "cfengine":"lucee@5"
    },
    "web":{
        "http":{
            "port":"55725" <-- select whatever port you want to use
        },
        "rewrites":{
            "enable":"true"
        },
        "aliases":{
            "/moduleroot/my-awesome-module":"../"  <-- very important! points to the directory above test-harness
        }
    },
    "openBrowser":"false",
    "cfconfig":{
        "file":"../.cfconfig.json" <-- use the cfconfig from the root of the project
    }
}

What does the Ortus team do? Do they take the same shortcut I did and launch servers from the test-harness folder for easy access to Coldbox watch and reinit commands? Or is there a better way to handle this type of situation?

2

One other thing I forgot…
If I do make a copy of server.json in test-harness, I need a way to reference the .env file from the project root. I looked at all the possible properties of server.json in the docs but didn’t see anything that might let me do that.

Then again, it looks like the template has a few keys that don’t exist in the documentation, so maybe there’s a way to do it similar to this:

"cfconfig": {
	"file" : ".cfconfig.json" <-- does not work
}

– Update –

I think the module-template may have the config.json file wrong. Based on what I read from the cfconfig docs, you can point to a different .cfconfig.json file like this:

"cfconfigFile":"../.cfconfig.json" <-- works

I also found a reference in the dotEnv docs that says you an add a key called dotenvFile, but it doesn’t seem to work in my sample app.

"dotenvFile":"../.env" <-- does not appear to work
3

Most of the Ortus peeps have different ways they like to do this. Having the test harness in the repo is Luis’s favoriate way, though we’ve waffled on whether to have the test harness in the root and the module in a sub folder or the module in a root and the test harness in the sub folder. I tend to do modules with a test suite of unit tests the latter way, but I don’t tend to have test harness in my repos at all. I’ll usually just package link the module to a separate app somewhere else.

Yep, that’s correct. If you cd into the web root, CommandBox will prolly find one of the servers, but if you start more than one server with that web root, it will just find the first. The coldbox watch-reinit command did have a directory param added to it recently for that purpose.

This should work. Enable the debugging features of the dotenv module to get more info. The dotenvfile path will be resolved relative to the path the server.json lives in.

1 Like
4

Thanks Brad. It makes me feel better that there are a couple of different approaches and no official “right way” yet.

I experimented a little more with the dotenv module to see if I could figure out what is going on. I’m not sure how to enable debugging features on the module, but I did try running dotenv show, and it shows the wrong .env file values.

In my test-harness folder I created a .env file with the key APPNAME=customenv. Then in the root, I create an .env file with the key APPNAME=rootenv. Then in server.json I set "dotenvFile":"../.env". When I start the server and execute dotenv show, I see APPNAME=customenv. So it looks like commandbox is using the test-harness .env file instead of the one specified in server.json.

How do I enable debugging mode in the dotenv module? I checked the readme but didn’t see anything.

5

dotenv show simply dumps out the contents of any .env file where you run that command. It’s not really going to tell you anything about what .env file(s) a given server will or will not load.

The settings are just module config settings that you’d set like any other module. As usual, you can use tab completion to “find” all the possible settings.config

config set modules.commandbox-dotenv.printOnLoad=true
config set modules.commandbox-dotenv.verbose=true