I use chalet as a server catalog. I have fixed ports set up for most services. I hit localhost:2000/server-name to get redirected to the port.

It takes 3-4 seconds to redirect sometimes, I'm wondering why it should take any time at all, what happens other than the redirect? Is there anything to configure to make it redirect without checks?

Thanks

Currently hotel and chalet allow a user/developer to start/stop each saved server from the daemon's web app (localhost:2000).

I would like to be able to start/stop/restart a saved server via the chalet CLI, as shown here:

chalet start --name myapp
chalet stop --name myapp
chalet restart --name myapp

Optionally Tail Server Output

For start and restart, I would like an option (enabled via a new CLI option such as --listen) to output the server's logs to STDOUT, so that I could run these commands from a terminal window (or VS Code terminal) and see the server logs right there. This listening/tailing of the server logs could be terminated by SIGTERM or SIGINT (ctrl-C), ending the CLI process and returning to the shell, but keeping the server running (until stopped in the Chalet daemon web app or via chalet stop --name myapp).

If Server Already Running

Running the start command and specifying a server that is already running should cause an error message to be emitted to STDERR:

"Server '<name>' is already running"

However, if the --listen option is given, then the CLI process should output the server's logs to STDOUT and continue to tail the logs until terminated by SIGTERM or SIGINT (ctrl-C).

Preserve Current Daemon Management via start/stop/restart

If the -n/--name argument is omitted, then start/stop/restart would manage the daemon, as they do now, so current usage of chalet start/stop/restart would not be affected in any way.

Hello

I've just installed chalet and then run 'chalet start'.
It's impossible for me to reach the webpage so I've been into the daemon.log and here is what I founded

I try to run it with Ubuntu 20 and node v10.19.0

Thanks in advance

We proxy a wildcard domain through to chalet. If we have a project with the word chalet in the subdomain, the proxying doesn't work, it instead just shows the chalet dashboard.

Bit of an odd one, and probably a bit of a rare bug. Just thought I'd mention it. I'm guessing you doing a match against the word for some reason.

Hey,

First thanks for maintaining this fork, its great :) On hotel there's an issue about .localhost domains and Chrome typicode#326. The gist is that Chrome bypasses the proxy for .localhost domains.

Just wondering if you'd accept a PR to change the default tld to '.test' so chalet can work out of the box with Chrome

I'm using chalet to run a local Node dev server, as follows:

chalet run 'npm start' --name myapp

When I press Ctrl-C to kill the dev server, I see this error:

^C/opt/homebrew/lib/node_modules/chalet/lib/cli/run.js:60
          status = _this$_spawnSync.status,
                                    ^

TypeError: Cannot read properties of undefined (reading 'status')
    at startServer (/opt/homebrew/lib/node_modules/chalet/lib/cli/run.js:60:37)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

alex@alex-brain ~/c/r/a/t/debug (content-negotiation ⚡↩=)> chalet add "./actix-example-server" --name schemas
Create ~/.chalet/servers/schemas.json
Output No log file specified (use '-o app.log')
Port Random port (use '-p 1337' to set a fixed port)
alex@alex-brain ~/c/r/a/t/debug (content-negotiation ⚡↩=)> ls
actix-example-server*  actix-example-server.d  actix-server*  actix-server.d  build/  deps/  examples/  incremental/  libactix_files.d  libactix_files.rlib  libactix_web.d  libactix_web.rlib
alex@alex-brain ~/c/r/a/t/debug (content-negotiation ⚡↩=)> chalet ls
schemas
~/c2/rust/actix-web/target/debug
./actix-example-server
alex@alex-brain ~/c/r/a/t/debug (content-negotiation ⚡↩=)> chalet run schemas
Create ~/.chalet/servers/debug.json
sh: 1: schemas: not found
(node:8995) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'status' of undefined
    at startServer (/home/alex/.config/yarn/global/node_modules/chalet/lib/cli/run.js:60:37)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:8995) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:8995) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Thought I'd report this here because Hotel isn't really maintained anymore. I'd appreciate any of your thoughts or if you could take a stab at fixing this.

Let me know if you need any more details. Thanks!

NAME="Ubuntu"
VERSION="19.10 (Eoan Ermine)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 19.10"
VERSION_ID="19.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=eoan
UBUNTU_CODENAME=eoan

$ node --version
v12.18.2
$ npm --version
6.14.5
$ yarn --version
1.22.0

typicode#309 and typicode#346. This would be really great.

Hi,

I upgrade node locally yesterday and seems theres an issue with proxying (maybe) on node 17.

I downgraded to node 16 and its working fine again.

This issue is so if anyone else comes along and is seeing the Chalet error page when proxying.

FYI - the localhost connection was working fine. It was the proxying to the .test domain that was failing.

Cheers
Lee

If there is already a saved server config for myapp, and a user runs the run command for another server named myapp, chalet will correctly report the name conflict:

Configuration already exists with name 'fp2' (use -f to force creation)

However, it then proceeds to run the specified command anyway, and when that command exits, it proceeds to remove the config file for the previously saved myapp server — thereby removing the myapp server from chalet.

This result is very destructive and unexpected — especially since chalet is already detecting the name collision. A previously saved server should never be modified or removed by the run command unless the --force option is given.

Even worse, this can happen even if the run command does not specify a -n/--name option — because it will use the current directory name as the default server name and will proceed to remove any saved server matching that name.

Unless the --force option is given, then there currently is no clean way to run a server (specified or derived from cwd) with the same name as an existing server, since the run command currently works by writing to a temporary config file (and thus would overwrite the existing server's config file). Therefore, if such a name collision is detected, then the run command should display the name-collision error message (as shown above) and then exit immediately.

I tried adding colima to chalet (added the command colima start.

When I turn it on, it starts the process and looks normal, but the switch shows it as "off".

Is it because something is getting forked or switching pids or something? or could it be a simpler explanation?

Thanks

Trying to figure out how to get a svelte-kit app (https://kit.svelte.dev) working in chalet. I can get the app running, but it keeps reloading. Svelte-kit apps use vite (https://vitejs.dev) for hot-module-reloading in development, and vite is trying to connect to wss://my-app.localhost:3000 and failing, so it tries reloading, infinitely. Not sure how to get this working so that chalet will forward those web socket connections through to the vite server. Here's my app config:

{
  "cwd": "/Users/pascal/Projects/my-svelte-app",
  "cmd": "npm run dev",
  "xfwd": true,
  "out": "app.log",
  "env": {
    "PATH": "[omitted]",
    "PORT": 3000
  }
}

I have self-signed SSL working, so the app loads at https://my-app.localhost, but it can't reach wss:my-app.localhost:3000

Will keep trying and report what I find but if anyone has any guidance I'd appreciate it.

Thank you for keeping this alive @jeansaad. It's hard to find some nice GUI for development on Windows.

I understand the utility is meant to be used locally, but there is also a nice opportunity to set up a dev environment for a new team member. They could simply configure their chalet to use servers from a folder that's versioned in the VCS.

Probably the easiest approach would be to add a configuration option with a list of additional folders with servers and it merges it all together. I could work on the PR if you think this is a good idea.

Maybe there is a viable approach through Docker, but I am mostly a front-end guy, so I am not sure.

First, thanks for maintaining this tool. Been using hotel for years and your battle against code rot is very much appreciated.

I expose my chalet setup via a reverse proxy, so clients can see work in progress. However I sometimes find they've restarted their dev site just by going to the provided domain. I obviously want to keep my dev machine running as few sites as possible, so it'd be good to disable this behaviour.

Is this something you would implement, or accept a pull request for? (unless this is already possible, but I missed it from the docs).

Thanks.

I'm working on a project and when updating to node 18 the monitors no longer seems to start correctly and its logs are not appearing to show correctly. Has anyone else run into this problem?

The TLDs do not work on Windows. localhost:2000/app works but app.localhost does not. I have setup the proxy according to the instructions.

I have restarted my browser and tried different browsers.

How can I start some servers automatically on restart of my machine ?

The chalet CLI has a run command, which sets up and runs a temporary server, outputs the server's logs to STDOUT, and removes the server config (to clean up) when the server process has stopped.

However, if I need to stop the server and restart it for some reason, then it will run under a different port number the second time (typically the next number in some sequence). If I switch to the browser tab where I had loaded the app in its first run, it will have the first port number in its URL, but that port number is no longer being used — therefore reloading that tab will fail with a server-not-found error.

It would be great if the chalet daemon would remember servers previously run and their assigned port numbers, so that if another server is run with the same name, the previously used port number could be reused. This could simply be an in-memory hash that would persist only while the chalet daemon is running. The run command would still clear the server's temporary config file when the run command exits, but just keep the port number in an entry for that server name in the daemon's memory.