shamefully-hoist = true

简介: shamefully-hoist = true

根目录下创建npm的配置文件.npmrc,增加配置项


shamefully-hoist = true 是一个在 pnpm(一个快速的、磁盘效率高的包管理器)中使用的配置选项。pnpm 的主要特点之一是它使用硬链接和符号链接来避免复制相同的包到每个项目的 node_modules 文件夹中,从而节省了大量的磁盘空间。然而,这种做法有时可能会与某些期望每个项目的 node_modules 文件夹都包含所有依赖的工具或脚本产生冲突。


当 shamefully-hoist 设置为 true 时,pnpm 会尝试模仿传统的 npm 和 yarn 行为,将所有依赖项都安装在项目的根 node_modules 文件夹中,而不是将它们分散到各个子文件夹中。这通常是为了解决某些与路径解析或特定工具集成相关的问题。


然而,需要注意的是,使用 shamefully-hoist 可能会失去 pnpm 的主要优势之一,即节省磁盘空间。此外,它还可能引入新的依赖解析问题,因为所有的包现在都位于同一级别,而不是它们各自的作用域中。


如果你想在 .pnpm-store 配置中启用 shamefully-hoist,你需要确保你在正确的位置进行设置。.pnpm-store 通常是 pnpm 用于存储已下载包的全局缓存的目录,而不是用于配置 pnpm 行为的地方。


通常,你可以在项目的 .npmrc 文件(位于项目根目录)或用户的主目录中的 .npmrc 文件中设置 shamefully-hoist。你也可以在运行 pnpm 命令时通过环境变量或命令行参数来设置它。

例如,在命令行中:

pnpm install --shamefully-hoist

或者在 .npmrc 文件中:

1. 
 
shamefully-hoist = true

但是,请记住,尽管 shamefully-hoist 可以解决某些问题,但它也可能引入新的问题,因此在使用它之前应该仔细考虑。如果可能的话,最好尝试找出导致你需要使用它的根本原因,并寻找其他解决方案。


在 pnpm 中,通常不会直接出现“幽灵依赖”这样的术语,但“幽灵依赖”通常指的是那些在项目代码中隐式依赖但并未在 package.json 文件中明确声明的依赖。然而,当你说“把所有依赖都提升到根目录”时,这实际上与 pnpm 的默认行为不符,因为 pnpm 默认就是使用内容可寻址的存储(Content-Addressable Storage, CAS)来管理依赖,而不是将它们都放在项目的根 node_modules 目录下。


但是,为了兼容某些工具或解决特定问题,pnpm 提供了 shamefully-hoist 配置选项。当这个选项被设置为 true 时,pnpm 会尝试模仿传统的 npm 或 yarn 的行为,即将所有依赖都安装在项目的根 node_modules 目录下,而不是将它们分散到各个子文件夹中。


这里是如何在 pnpm 中设置 shamefully-hoist 的:


在命令行中:

你可以在安装时直接指定这个选项:


bash复制代码

pnpm install --shamefully-hoist

  1. 但是,请注意,这只会在这次安装时生效。
  2. .npmrc 文件中
    你可以在项目根目录下的 .npmrc 文件中设置这个选项,这样它就会一直生效:

复制代码

shamefully-hoist = true

然而,需要强调的是,虽然 shamefully-hoist 可以解决某些与路径或特定工具集成相关的问题,但它也会失去 pnpm 的主要优势之一,即节省磁盘空间。同时,这也可能引入新的依赖解析问题,因为所有的包现在都位于同一级别,而不是它们各自的作用域中。


如果你发现自己经常需要使用 shamefully-hoist,那么可能需要重新考虑你的项目结构或依赖管理方式,以更好地利用 pnpm 的优势。同时,确保你的项目没有“幽灵依赖”也是一个好习惯,这可以通过检查项目代码和确保所有依赖都在 package.json 中明确声明来实现。


目录
相关文章
vite环境引入web worker方法
在 vite 环境中使用 web worker 时,如果遇到生产环境中 worker.js 文件的 MIME 类型被识别为 text/html,导致报错无法运行的情况时,可以参考以下两种方法,原理都是避免编译时产出单独的 worker.js 文件。方法一worker文件不需要包装,引入时后缀增加 ?worker&inline,使用时直接 new ImportedWorker();self.
1734 1
|
前端开发
在微前端qiankun中使用Vite你踩坑了吗?(下)
哈喽,我是树酱。之前搭建的微前端体系已经稳步运行将近两年了,最近遇到一些童鞋反馈。之前据说qiankun并不支持Vite打包的应用,那是不是我就无法使用了?
3419 0
在微前端qiankun中使用Vite你踩坑了吗?(下)
|
8月前
|
人工智能 JavaScript Devops
如何在云效中使用 DeepSeek 等大模型实现 AI 智能评审
除了代码智能补全外,AI 代码智能评审是 DevOps 领域受开发者广泛关注的另一场景了。本文,我们将结合云效代码管理 Codeup、流水线 Flow 和 DeepSeek,分享一种企业可快速自主接入,即可实现的 AI 智能评审解决方案,希望给大家一些启发。
362 18
|
JavaScript 前端开发
前端 JS 经典:统一 Vite 中图片转换逻辑
前端 JS 经典:统一 Vite 中图片转换逻辑
336 0
|
缓存 JavaScript API
Vue3— computed的实现原理
【9月更文挑战第5天】Vue3— computed的实现原理
386 10
|
开发工具 git
Stylelint——Unexpected unknown pseudo-class selector ":deep" selector-pseudo-class-no-unknown
新项目制定规范接入了stylelint,并通过husky在git提交时去触发检测修复,使用`:deep()`的时候却发现了报错;
463 1
|
前端开发 JavaScript
vite中css最佳实践:使用postcss完善项目中的css配置
【8月更文挑战第3天】使用postcss完善项目中的css配置
3316 1
|
API
Vue3组件通信全解析:利用props、emit、provide/inject跨层级传递数据,expose与ref实现父子组件方法调用
Vue3组件通信全解析:利用props、emit、provide/inject跨层级传递数据,expose与ref实现父子组件方法调用
3214 0
|
监控 程序员 开发工具
如何规范Git提交-参考阿里云开发者社区
这篇文章分享了如何规范Git提交,介绍了commit message的格式规范,并通过webhook监控机制来确保代码提交的规范性,从而提高研发效率和代码维护质量。
|
API 开发者 Java
API 版本控制不再难!Spring 框架带你玩转多样化的版本管理策略,轻松应对升级挑战!
【8月更文挑战第31天】在开发RESTful服务时,为解决向后兼容性问题,常需进行API版本控制。本文以Spring框架为例,探讨四种版本控制策略:URL版本控制、请求头版本控制、查询参数版本控制及媒体类型版本控制,并提供示例代码。此外,还介绍了通过自定义注解与过滤器实现更灵活的版本控制方案,帮助开发者根据项目需求选择最适合的方法,确保API演化的管理和客户端使用的稳定与兼容。
684 0