#node.js #typescript #npm #typescript-typings
Вопрос:
Я хочу знать, есть ли способ:
- устанавливайте только необходимые зависимости для сборки, избегая 150 МБ мусора;
- строить;
- затем удалите зависимости, необходимые только для сборки, но не для запуска.
Сейчас в этом больше сомнений, чем необходимости
У меня есть следующие зависимости:
"devDependencies": {
"@types/node": "^16.0.0",
"@typescript-eslint/eslint-plugin": "^4.31.1",
"@typescript-eslint/parser": "^4.31.1",
"commitizen": "^4.2.4",
"cz-conventional-changelog": "3.3.0",
"eslint": "^7.12.1",
"eslint-config-prettier": "^8.3.0",
"eslint-config-standard": "^16.0.3",
"eslint-plugin-import": "^2.22.1",
"eslint-plugin-node": "^11.1.0",
"eslint-plugin-prettier": "^4.0.0",
"eslint-plugin-promise": "^5.0.0",
"prettier": "^2.4.1",
"ts-node-dev": "^1.1.8",
"typescript": "^4.3.5"
},
"dependencies": {
"dotenv": "^10.0.0"
}
И я кое-что заметил, у меня много бесполезных зависимостей при компиляции typescript, потому что только для компиляции мне нужно всего 3:
"devDependencies": {
"@types/node": "^16.0.0",
"typescript": "^4.3.5"
},
"dependencies": {
"dotenv": "^10.0.0"
}
Только эти 3 зависимости имеют размер 60 МБ, и если я действительно захочу, я могу скомпилировать, удалить зависимости и использовать npm install --production
то, что позволит мне использовать ~1 МБ, что для меня отлично, потому что финал может быть максимально легким (немного преувеличено, но круто).
Теперь, когда я делаю все npm install
возможное со всеми зависимостями, я достигаю 150 МБ (это действительно разочаровывает).
Мой вопрос в том, есть ли способ минимизировать установку зависимостей в процессе сборки, кроме перемещения типов в зависимости (потому что они не являются «производственными» зависимостями, только для «сборки»)?
На самом деле, когда я строю, я делаю это:
npm i
npm run build
rm -rf node_modules # not sure if needed
npm i --production
Это создаст небольшую сборку, но в процессе мне нужно будет установить около 150 МБ ненужных пакетов.
Примечания:
- Я думал о том, чтобы удалить его перед сборкой, но я хочу избежать этого
- Я думал о дополнительных зависимостях, но, похоже, у них нет этой цели
- Я хочу сохранить зависимости, потому что они обеспечивают согласованность кода при работе с другими людьми и помогают избежать ошибок
- «большая» зависимость
typescript
имеет 61 М, а вторая-prettier
20 М, мне нужно толькоtypescript
построить, но мне не нужно, чтобы кто-то из них работал. - Я просто хочу «решить» эту проблему при создании, на самом деле меня это не волнует при написании кода
- Проблема здесь не в окончательной сборке, а в процессе загрузки ненужных зависимостей
Комментарии:
1. зачем ты это делаешь
rm -rf node_modules
? например, беспокоит ли вас дисковое пространство или необходимость загружать их каждый раз? потому что просто не удаляя node_modules, вы, несомненно, уменьшите количество, которое нужно устанавливать каждый раз.2. Я чувствую, что ваш процесс сборки, вероятно, должен выглядеть так, как
npm i --production
тогдаnpm run build
, без каких-либо других шагов.3.
install only the needed dependencies to build avoiding 150MB of garbage;
. Ну, если вы его создаете, то эти 150 МБ не являются мусором, они буквально являются зависимостями, необходимыми для создания вашего пакета.4. @DavidNithaelTorresLima — я хочу сказать, что typescript-это зависимость от честности для создания. Вы не смогли бы создать свое приложение из исходного кода (чтобы оно могло работать где угодно) без наличия машинописного текста. Мое второе замечание заключается в том, что невозможно провести различие между машинописным текстом (что-то требуется для создания вашего приложения) и более красивым (что-то не требуется для создания вашего приложения). Хотя это действительно ставит интересный вопрос
5. @DavidNithaelTorresLima как я уже сказал, вы задали интересный вопрос. Быстрый поиск в Google не дал RFC для этой функции (я бы назвал их «Зависимостями от сборки») или чем-то еще, но я нашел github.com/itsthatguy/group-dependencies
Ответ №1:
Проблема здесь не в окончательной сборке, а в процессе загрузки ненужных зависимостей
Делается ли это в докере?
Для этого существует решение — вы кэшируете зависимости на основе содержимого пакета-lock.json или yarn.lock
https://medium.com/@stepanvrany/how-to-build-nodejs-docker-image-using-cache-c401137661d0
Комментарии:
1. Да, я думал об этом, и это могло бы ускорить процесс, но мне все равно нужно было бы кэшировать эти ненужные зависимости.
2. Моя настоящая забота здесь-узнать, есть ли способ избежать этого, но просто из любопытства.
3. @DavidNithaelTorresLima
if there is a way to avoid it
Нет.4. Честно говоря, это немного грустно, но спасибо, если когда-нибудь мне это понадобится по какой-либо причине, я могу создать скрипт для редактирования зависимостей перед установкой
5. @DavidNithaelTorresLima — дело в том, что в типичном конвейере CI/CD компоновка и тестирование часто выполняются в рамках одного и того же процесса CI, который строит код из исходного кода. Это делает возможность установки тестовых зависимостей, зависимостей lint и зависимостей сборки отдельно не очень полезной.