Определение синглтоноподобных контейнерных объектов... и сохранение tslint счастливым

Question

У меня большой проект TypeScript, и я недавно добавил tslint, чтобы применить некоторые базовые правила стиля кода. Это было в основном безболезненно, но есть еще одна вещь, которую я все еще подвергаю сомнению.

У меня есть несколько кусков кода, где у меня есть объект, похожий на одиночный объект, который оборачивает некоторые свойства и функции. Представьте себе что-то вроде:

function open(x) {...};
function close(x) {...};
let isOpen = false;

export const MainMenu {
    open,
    close,
    isOpen
};

Но проблема в том, что tslint жалуется на именование MainMenu, потому что я сказал ему принудительно применять имена переменных camelCase. При всех обстоятельствах, кроме этого, соглашение остается в силе, и в таких ситуациях, как это, я думаю, что это правильно, если быть в верхнем регистре (Math, Reflectи т.д. все следуют этому соглашению).

Так что мне здесь делать? Я мог бы либо отключить правило всякий раз, когда это происходит, либо, возможно, namespace концепция больше подходит для этого? Но тогда я использую внешние модули, поэтому я не знаю, должен ли я. Кроме того, namespace-с затруднить добавление членов собственности.

Любые советы приветствуются.

Answer 1

В целом это больше похоже на область, где я бы использовал namespace (или, возможно, отдельный внешний модуль? Тогда в вашем текущем модуле вы можете реэкспортировать его.)

Но допустим, что вы действительно хотите так поступить и хотите сделать TSLint счастливым. Ваше самое простое решение - просто временно отключить variable-name:

/* tslint:disable:variable-name */
export const MainMenu {
    open,
    close,
    isOpen
};
/* tslint:enable:variable-name */

(Обратите внимание, что вы можете переместить комментарий для повторного включения на несколько строк - я просто предпочитаю его там, где он есть, в эстетических целях.)

Существует также текущий запрос функции для способа исключить определенные переменные из этого правила в вашем tslint.json файл. Так что в будущем это может быть вариантом!