Надёжно – никак. Если код выполняется на стороне клиента, то он должен до этого клиента дойти. Если код дошёл до клиента, то он может быть расшифрован и проанализирован. Единственный подход, позволяющий надёжно скрыть код в вебе – это выполнять его на сервере, а клиенту присылать результаты его работы.
Но как быть, если у вас клиентское приложение? Ответ на этот вопрос зависит от цели, для которой вам нужно скрывать код. Если этот код содержит какую-то логику, обеспечивающую безопасность, то нужно как можно быстрее пересмотреть архитектуру и задачи аутентификации-авторизации-валидации перенести на сервер. Клиентский код не может и не должен проверять права и подписи, это открытая уязвимость.
Если же вы опасаетесь, что конкурент возьмёт ваш код и удешевит таким образом свою разработку, то надёжно скрывать код для этого не нужно. Нужно, чтобы стоимость анализа такого кода была выше, чем написание аналогичного кода заново. Как правило, для решения этой задачи хватает стандартной минификации и обфускации.
Стоит добавить, что исполняемый JS может быть написан на другом языке, и после скомпилирован в JS. Обратный перевод в исходники при таком процессе невозможен. Впрочем, обфускация работает по схожему принципу. Ещё один вариант – это выполнять критичный код на web assembly, например переведя его на AssemblyScript. Тогда он компилируется в байткод, анализ которого будет в разы сложнее. Но это всё полумеры, при должных вложениях времени и сил алгоритм может быть проанализирован и модифицирован. Любой локальный код можно взломать.
Поэтому правильный ответ такой – решайте проблемы по мере поступления. Помимо обычной минификации нет смысла как-то специально запутывать любой свой код "на всякий случай", никто так не делает за ненадобностью. Если же вы столкнулись с конкретным случаем, где это необходимо, нужно понять, какие именно факторы делают этот случай особенным, и решать данную конкретную задачу.