But then, who will maintain the code?

Sacrifice 1000 programmers, got it

Circular dependencies can be removed in almost every case by splitting out a large module into smaller ones and adding an interface or two.

In your bot example, you have a circular dependency where (for example) the bot needs to read messages, then run a command from a module, which then needs to send messages back.

    v-----------\
  bot    command_foo
    \-----------^

This can be solved by making a command conform to an interface, and shifting the responsibility of registering commands to the code that creates the bot instance.

    main <---
    ^        \
    |          \
    bot ---> command_foo

The bot module would expose the Bot class and a Command instance. The command_foo module would import Bot and export a class implementing Command.

The main function would import Bot and CommandFoo, and create an instance of the bot with CommandFoo registered:

// bot module
export interface Command {
    onRegister(bot: Bot, command: string);
    onCommand(user: User, message: string);
}

// command_foo module
import {Bot, Command} from "bot";
export class CommandFoo implements Command {
    private bot: Bot;

    onRegister(bot: Bot, command: string) {
        this.bot = bot;
    }

    onCommand(user: User, message: string) {
        this.bot.replyTo(user, "Bar.");
    }
}

// main
import {Bot} from "bot";
import {CommandFoo} from "command_foo";

let bot = new Bot();
bot.registerCommand("/foo", new CommandFoo());
bot.start();

It's a few more lines of code, but it has no circular dependencies, reduced coupling, and more flexibility. It's easier to write unit tests for, and users are free to extend it with whatever commands they want, without needing to modify the bot module to add them.

It does not get more complicated to split your example. What gets more complicated is giving all sort of unrelated responsabilities to a single class, simply because it is the path of least resistance.

In your example, all you need is an extra module listening for configuration changes and reacting to it. This way you leave your context-specific logic out of your data model, no need for cyclic dependency. There are so many downsides to cyclic dependency, to justify it because splitting your logic is "too complicated" really isn't a strong argument.