Я имел ввиду количество файлов внутри node_modules. Однако, кажется, оно ненамного меньше, не похоже чтобы существенно меньше, даже если аккуратно пытаться определить, а определить тяжело, потому что много факторов на это влияет.
npm dedupe, уменьшает дублирование, которое возникает из-за разницы в разрешении версий запрошенных пакетов по пересекающимся semver ranges, например c@1.0.x и c@~1.0.9 могут быть разрезолвлены в c@1.0.3 и в c@1.0.10 в разных частях графа зависимостей, а могут быть разрезолвлены оба в с@1.0.10. npm dedupe анализирует lock файл и пытается проапгрейдить resolution для зависимостей по пересекающимся semver ranges с целью, чтобы их было как можно меньше.
Это уменьшает node_modules и убирает из него дублирование, но не полностью, там все равно остается существенное дублирование, из-за конфликтов версий пакета с одним и тем же именем по разным путям графа, или из-за того, что без дублирования невозможно соблюсти гарантии peer dependencies.
Есть разное дублирование. Да, дублирование между контейнерами pnpm не уменьшает. pnpm решает другую задачу - дублирование файлов и пакетов внутри node_modules и таким образом размер Docker-контейнера будет меньше.
Симлинки не будут ссылаться на содержимое других контейнеров, симлинки будут внутри node_modules и за счет этого установка будет быстрее и места в контейнере будет требоваться меньше
pnpm будет экономить место и время установки node_modules за счет использования симлинков в вашем Docker-контейнере. Если симлинки не совместимы по каким-то причинам с вашим проектом вы также можете попробовать Yarn 3.0+, он поддерживает классическую структуру node_modules с хардлинками на контенто-адресуемое хранилище (nmMode: hardlinks-global) либо локально в проекте (nmMode: hardlinks-local), как результат - очень хорошая совместимость с экосистемой пакетов npm + экономия места в Docker-контейнере
Хардлинки могут использоваться внутри node_modules, но pnpm так не делает. Если использовать хардлинки внутри node_modules, скорость записи пакетов в node_modules будет меньше, потому что на скорость больше всего влияет количество записываемых файлов, а не их общий размер (то что хардлинки экономят место не означает что создание копий мгновенно). Тот режим о котором вы пишете - классическая структура node_modules но с хардлинками для экономии места реализован в Yarn 3.0+, nmMode: hardlinks-local - для использования хардлинков внутри проекта, есть еще nmMode: hardlinks-global - для использования хардлинков, указывающих на общее хранилище адресуемое контентом (примерно так же как делает это pnpm, но без симлинков)
Дело не только в месте. У него еще и скорость установки node_modules выше, за счет меньшего количества файлов. Также он предотвращает доступ к незадекларированным зависимостям (уровень контроля определяется настройками)
Это сделано и на симлинках (внутри node_modules) и на хардлинках файлов из node_modules на общее хранилище адресуемое на основе контента (используется хэш от контента). Симлинки предназначены для исключения дублирования одних и тех же пакетов внутри node_modules (дедупликации), а также для ограничения использования незадекларированных зависимостей. Обратная сторона симлинков - ухудшение совместимости с существующей экосистемой npm. Положительная сторона - минимизация ошибок доступа к незадекларированным зависимостям при разработке большими командами.
Yarn 3.0 и выше тоже поддерживает установку с использованием контентно-адресуемой файловой-системы, причем с классическим расположением файлов и директорий в `node_modules`, без симлинков (опции `nodeLinker: node-modules` и `nmMode: hardlinks-global`).
Я имел ввиду количество файлов внутри node_modules. Однако, кажется, оно ненамного меньше, не похоже чтобы существенно меньше, даже если аккуратно пытаться определить, а определить тяжело, потому что много факторов на это влияет.
npm dedupe, уменьшает дублирование, которое возникает из-за разницы в разрешении версий запрошенных пакетов по пересекающимся semver ranges, например c@1.0.x и c@~1.0.9 могут быть разрезолвлены в c@1.0.3 и в c@1.0.10 в разных частях графа зависимостей, а могут быть разрезолвлены оба в с@1.0.10. npm dedupe анализирует lock файл и пытается проапгрейдить resolution для зависимостей по пересекающимся semver ranges с целью, чтобы их было как можно меньше.
Это уменьшает node_modules и убирает из него дублирование, но не полностью, там все равно остается существенное дублирование, из-за конфликтов версий пакета с одним и тем же именем по разным путям графа, или из-за того, что без дублирования невозможно соблюсти гарантии peer dependencies.
Есть разное дублирование. Да, дублирование между контейнерами pnpm не уменьшает. pnpm решает другую задачу - дублирование файлов и пакетов внутри node_modules и таким образом размер Docker-контейнера будет меньше.
Симлинки не будут ссылаться на содержимое других контейнеров, симлинки будут внутри node_modules и за счет этого установка будет быстрее и места в контейнере будет требоваться меньше
pnpm будет экономить место и время установки node_modules за счет использования симлинков в вашем Docker-контейнере. Если симлинки не совместимы по каким-то причинам с вашим проектом вы также можете попробовать Yarn 3.0+, он поддерживает классическую структуру node_modules с хардлинками на контенто-адресуемое хранилище (nmMode: hardlinks-global) либо локально в проекте (nmMode: hardlinks-local), как результат - очень хорошая совместимость с экосистемой пакетов npm + экономия места в Docker-контейнере
Хардлинки могут использоваться внутри node_modules, но pnpm так не делает. Если использовать хардлинки внутри node_modules, скорость записи пакетов в node_modules будет меньше, потому что на скорость больше всего влияет количество записываемых файлов, а не их общий размер (то что хардлинки экономят место не означает что создание копий мгновенно). Тот режим о котором вы пишете - классическая структура node_modules но с хардлинками для экономии места реализован в Yarn 3.0+, nmMode: hardlinks-local - для использования хардлинков внутри проекта, есть еще nmMode: hardlinks-global - для использования хардлинков, указывающих на общее хранилище адресуемое контентом (примерно так же как делает это pnpm, но без симлинков)
Дело не только в месте. У него еще и скорость установки node_modules выше, за счет меньшего количества файлов. Также он предотвращает доступ к незадекларированным зависимостям (уровень контроля определяется настройками)
Это сделано и на симлинках (внутри node_modules) и на хардлинках файлов из node_modules на общее хранилище адресуемое на основе контента (используется хэш от контента). Симлинки предназначены для исключения дублирования одних и тех же пакетов внутри node_modules (дедупликации), а также для ограничения использования незадекларированных зависимостей. Обратная сторона симлинков - ухудшение совместимости с существующей экосистемой npm. Положительная сторона - минимизация ошибок доступа к незадекларированным зависимостям при разработке большими командами.
Yarn 3.0 и выше тоже поддерживает установку с использованием контентно-адресуемой файловой-системы, причем с классическим расположением файлов и директорий в `node_modules`, без симлинков (опции `nodeLinker: node-modules` и `nmMode: hardlinks-global`).