Как установить только зависимости машинописного текста и построить (package.json, npm), избегайте 150 МБ зависимостей при построении

#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 и зависимостей сборки отдельно не очень полезной.