npm嵌套依赖管理 [英] npm nested dependency management

查看:87
本文介绍了npm嵌套依赖管理的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我对管理npm嵌套依赖项的最佳做法有疑问.

I have a question about best practices in managing npm nested dependencies.

让我解释一下我的处境,请告诉我我做错了什么,或者解决这个问题的最佳方法是什么.

Let me explain my situation, and please tell me what I'm doing wrong, or what's the best way to approach this.

我正在nodeenv中使用express.js和express-mongostore运行一个应用程序.由于nodeenv,我正在全局npm-ing一切,所以它们都放在nenv/lib/node_modules文件夹下.事情是,我正在尝试开发前沿的express.js,而express-mongostore已有一段时间没有更新了.安装完两个模块后,我得到了这个文件夹结构.

I'm running an app using express.js and express-mongostore in a nodeenv. Because of nodeenv, I'm npm-ing everything globally so they all go under the nenv/lib/node_modules folder. The thing is, I'm trying to develop off bleeding edge express.js while express-mongostore hasn't been updated in a while. After installing both modules, I get this folder structure.

nodeenv / lib / node_modules / express / node_modules / connect / ..
                             /
                             / connect-mongodb / node_modules/ connect / ...

所以最终发生的事情是我有2个不同版本的connect.

So what ends up happening is that I have 2 different versions of connect.

我之所以被烧死是因为mongodb存储生成的cookie和会话中间件生成的cookie不同,因为它们指向2种不同的connect utils实现(一个调用存储的utils,另一个直接调用utils.不幸的是,它们在需要解决期间指向不同的文件).实际的区别在于它们使用不同的算法对Cookie进行签名.有一段时间,我的会话使每次页面加载都失效了,这花了我很长时间才能调试到这个级别.

I got burnt because the cookie generated by the mongodb store and the one generated by the session middleware is different because they point to 2 different connect utils implementation (one calls the store which calls utils and the other calls utils directly. Unfortunately, they point to different files during require resolution). The actual difference here is that they sign the cookie using different algorithms. For a while, my sessions were invalidating themselves every page load and it took me a long while to debug down to this level.

我正在互联网上阅读,看来这应该是npm的方式,也是一件好事.这里的问题是,由于express依赖于connect中的一堆utils,而connect-mongodb继承了connect中的某些相同的类,因此使它们成为不同的存储库是有问题的.

I was reading on the Internets and it seems like this is supposed to be the npm way and a good thing. The issue here is that since express relies on a bunch of utils in connect and connect-mongodb inherits some of the same classes in connect, having them be different repos is problematic.

我目前仍然有2个版本的connect,我对其中一个进行了修补,使其与另一个类似.显然,这不是一个可持续的解决方案.在这种情况下,我应该如何继续进行依赖管理?

I currently still have 2 versions of connect and I patched one to be like the other. It is obvious that this is not a sustainable solution. How should I proceed and approach dependency management in this case?

提前谢谢!

推荐答案

您可以运行 npm dedupe 将兼容的依赖关系上移到树上.因此,假设express和connect-mongodb可以使用相同版本的connect,那么您将得到一棵像这样的树:

You can run npm dedupe to move compatible dependencies up the tree. So, assuming that express and connect-mongodb can work with the same version of connect, you'll end up with a tree like this:

nodeenv / lib / node_modules / express / ... 
                             /
                             / connect-mongodb / ...
                             /
                             / connect / ...

这篇关于npm嵌套依赖管理的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆