Easy: don’t use RiveScript.js in the web browser.
You can use RiveScript.js in a nodejs server instead, and have the web front-end make ajax requests to get a reply from the bot. That way the bot’s source code (.rive files) aren’t downloaded and cached by the browser, and it has to ping your back-end server to get a reply. It keeps the bot being a “black box” this way; all the browser can do is input a message and see how the bot responded, but the user can’t see why (ie. they don’t get the .rive source code).
The Perl, Python and Java versions of RiveScript can similarly be used as a back-end server-side language. In the case of Perl and Python you could write a CGI script that gets called via an ajax request from the front-end.
Anyway, this is why “Software as a Service” (SaaS) is a big thing with tech companies these days. If you give the user some software to run on their own computer (example: a video game, Adobe Photoshop, etc.) then all bets are off and the user will be able to hack it apart and get at its inner workings one way or another. If RiveScript were able to be compiled into a binary form or encrypted/obfuscated somehow, it wouldn’t do anything except delay somebody who really wants to get at the source code (for example, they could modify RiveScript.js to just dump out its memory after it had loaded the reply files, making any layers of encryption or obfuscation a moot point). So some companies decide it’s better to run their source code from a server, not giving the code (even in compiled .exe form) to the end users, so therefore it’s impossible for anybody to get into the code and find out its secrets.