Создать машинописный текст приложения React: только транспилить, не проверять тип, не анализировать
У меня есть небольшой проект React, который я хочу развернуть на экземпляре Google Compute Engine с ограниченным объемом оперативной памяти, менее 1,5 ГБ.
При сборке рабочей версии моего приложения линтер машинописного текста и компилятор обычно используют около 2 ГБ ОЗУ для переноса крошечного проекта, поэтому при развертывании у экземпляра Compute Engine заканчивается оперативная память до того, как проект может быть собран.
Как я могу заставить компилятор Typescript ничего не делать, кроме как пытаться преобразовать в javascript? Никакой проверки lint, никаких проверок правил конфигурации ts, абсолютно ничего, кроме самого минимума: транспиляция приложения?
Я просмотрел все флаги для tsConfig, и даже наименее строгий вариант по-прежнему требует слишком многого.
Спасибо
Ответы 2
После того, как проект будет создан для производства, у вас должна быть папка build, которую можно развернуть в вашем экземпляре Google Compute Engine. На данный момент это просто набор HTML, JavaScript и CSS. Использование оперативной памяти должно быть незначительным, так как в этот момент не происходит транспиляции, обслуживаются только статические файлы.
Однако если вы развертываете весь свой исходный код в Google Compute Engine и используете задачу npm «start», то вы транспилируете все это прямо здесь и сейчас. Это не рекомендуемый подход.
Лучше всего использовать веб-сервер, например nginx или express, для обслуживания статических файлов, созданных сборкой.
Вы правы, встроенные файлы не должны возвращаться в систему контроля версий, но это не имеет ничего общего с развертыванием. Похоже, вы прошли большую часть пути, и настоящая проблема заключается в том, что вы развертываете свой исходный код, когда вам действительно нужны только предварительно созданные статические файлы + ваш экспресс-сервер. Нет никакой причины создавать проект на цели развертывания.
Благодарю. У меня есть нубский вопрос; как бы вы развернули встроенные файлы на сервер? Я использовал git в качестве системы развертывания. Быстрый рывок, сборка, затем бег.
Я не знаком конкретно с облаком Google, но я был бы удивлен, если бы у них не было возможности FTP. Или, если это виртуальная машина, над которой у вас есть полный контроль, ничто не мешает вам установить собственный FTP-сервер. Если это Windows, вы можете использовать удаленный рабочий стол для копирования файлов из вашей локальной системы. Если это Linux и вы подключаетесь через SSH, вы можете использовать scp для копирования файлов.
У меня есть полный контроль над виртуальной машиной, я рассмотрю возможность использования FTP. Спасибо! Забавно то, что я уже использовал это для переменных среды, предоставляемых сервером метаданных Google Cloud. Я могу просто положить туда каталог сборки и вытащить его таким же образом.
Он говорит о проблеме времени сборки, а не о проблеме времени выполнения.
@KazuyaGosho Да, это то, что мы обсуждали. Этот ответ не относится к проблеме времени выполнения. Я не понимаю, что ты говоришь.
Краткий ответ: нет, вы не можете отключить проверку типов с помощью приложения Create React (CRA).
Подробности
Невозможно отключить проверку TypeScript, поэтому все, что вы можете сделать, это eject или react-app-rewired и написать свою собственную конфигурацию Babel.
Я рекомендую полностью удалить CRA, затем написать конфигурацию веб-пакета самостоятельно и использовать с ней опцию ts-loader transpileOnly.
Если вы просто хотите скомпилировать независимо от ошибок TS, вы должны установить следующую переменную среды.
TSC_COMPILE_ON_ERROR=true
Это заставляет CRA компилироваться, даже если проверка TypeScript не удалась. Однако он не отключает проверку типов, но не приводит к ошибкам TypeScript.
У меня сложилось впечатление, что встроенные файлы не следует проверять в системе контроля версий? Весь проект представляет собой экспресс-сервер, и я обслуживаю собранные с него статические файлы. Сценарий запуска запускает команду сборки машинописного текста, запускает сервер, а затем обслуживает статические файлы. Просто не хватает памяти на этапе сборки.