В компиляторе языка программирования TypeScript есть возможность генерации JavaScript с использованием "внутренних модулей", при этом на выходе получается один файл.
{
"compilerOptions": {
"target": "es3",
"outFile": "./build/build.js",
"rootDir": "./src/",
}
}
Тем не менее, судя по популярности того же WebPack, идея не прижилась. Что послужило причиной такой ненависти к внутренним модулям TypeScript и почему их не рекомендуют использовать?
Каноничный TypeScript с внутренними модулями дольше компилировать при ОГРОМНОМ количестве файлов, относительно кода с внешними модулями, где можно просто удалить весь синтаксис типизации. Как следствие, он не отвечает требованиям разработки кода крупных предприятий, где пересборка всего проекта невозможна из-за временных ограничений.
Тем не менее, нужно понимать, что внутренние модули это НЕ плохо. Они просто другие. В малых проектах частного разработчика они гораздо удобнее внешних модулей. Что хорошо предприятиям - смерть частному разработчику. Если конфигурацию компилятора typescript нужно настроить один раз, то связку webpack+babel нужно постоянно поддерживать, что в сочетании с возникновением конфликтов версий между пакетами npm требует отдельных рук.
На относительно не большом количестве файлов, разницы по времени компиляции не будет. Следует заметить, что сам компилятор TypeScript использует именно ВНУТРЕННИЕ модули. Поэтому, для частного разработчика будет лучше именно этот подход.
Для огромного количества JavaScript-библиотек, существуют дистрибутивы для классического подключения через тег на самой веб-странице. В сочетании с файлами типизации из репозитория DefinitelyTyped, можно отказаться от геморроя с npm, не потеряв статическую проверку типов.
Задача: Хочю написать на Nodejs програмку аналогичную Clickermann
есть простой тестовый блокКоторый имеет width 0 но при клике добавление класса у него появляется width 40%