blocks|key|1204101|text|不，在您的项目中添加大约900个包依赖项是没有意义的，仅仅因为您想添加一些模板。但这取决于你！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1204102|模板的沉重不是对node.js生态系统的挑战，也不是对他的主要软件包系统npm的挑战。|1204103|事实上，javascript社区往往使最小的模块负责一项任务，而只负责一项任务。我想这不是件坏事。但它可能会导致项目中存在大量依赖项的情况。|1204104|如今，硬盘内存很便宜，没有人再关心如何开发高效/小型应用程序了。|1204105|和往常一样，这只是一个选择的问题。|1204106|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

No, there is no point to add about 900 packages dependencies in your project just because you want to add some template. But it is up to you!

The heavyness of a template is not challenging the node.js ecosystem nor his main package system npm.

It is a fact that javascript community tend to make smallest possible module to be responsible for one task, and just one.
It is not a bad thing I guess. But it could result of a situation where you have a lot of dependencies in your project.

Nowadays hard drive memory is cheap and nobody cares any more about making efficient/small apps.

As always, it's only a matter of choice.

blocks|key|2496767|text|这是一个很好的问题，有几件事我想指出。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2496768|+V8引擎、节点模块(依赖项)和V8(对它们进行)|offset|length|style|BOLD|2496769|Node.JS是建立在V8引擎上的，它的源代码是C%2B%2B。这意味着Node.js的依赖关系基本上是用C%2B%2B编写的。|2496770|现在，当您使用require作为依赖项时，您将从c%2B%2B程序或js库中取出代码/函数。这就是如何建立库/依赖关系的方法。|CODE|2496771|库有如此多的函数，因此您将不使用|2496772|例如，看看快速验证器模块。它在那里有很多功能。当您需要模块时，您是否使用它提供的所有功能？答案是no。人们需要这样的包只是为了使用它的一个好处，所有的功能最终都会被下载，这就占用了不必要的空间。|2496773|将从其他节点依赖项生成的节点依赖视为解释语言。|2496774|示例:+Javascript是用C/C%2B%2B语言编写的，这些语言是用汇编编写的。把它想象成一棵树。您每次都创建新的分支，以便更方便地使用，最重要的是节省时间。它能让事情变得更快。这是创建新依赖项的类似情况，当人们使用已经存在的依赖项(require)创建新的依赖项时，而不是编写完整的C%2B%2B程序或JS脚本，因为这使一切变得更容易。|2496775|当需要其他NPMs来创建新的时，就会出现问题。|2496776|当依赖关系的作者需要其他依赖项来使用它们的一些(少量)好处时，他们最终会下载所有这些依赖项(他们并不真正关心这些依赖项，因为他们大多数不担心大小，或者他们宁愿这样做，也不愿意显式地编写新的依赖项或C%2B%2B插件)，这需要额外的空间。例如，您可以看到表达式验证器模块使用从这个链接。的依赖关系。|2496777|因此，当您有使用大量依赖项的大型项目时，您最终会占用它们太多的空间。|2496778|解决此的方法|2496779|编号1|2496780|这需要一些Node.JS专家。为了减少下载包的数量，专业的Node.JS开发人员可以转到模块保存的目录中，打开javascript文件，查看它们的源代码，并删除它们在不改变包结构的情况下不会使用的功能。|2496781|2号(很可能不值得你花时间)|2496782|您还可以创建用C%2B%2B或更好的JS编写的个人依赖关系，这实际上会占用尽可能少的空间(取决于程序员)，但减少一些大小而不是做工作需要花费最耗时、效率最低的时间。(注意:大多数依赖项都是用JS编写的)|2496783|编号3(公共)|2496784|而不是使用选项2，您可以实现WebPack。|2496785|结论与注记|2496786|所以从根本上说，下载所有的节点包是不可能的，但是如果你相信你能做到的话，你可以使用解决方案1，这也有可能破坏依赖的整个意图。(因此，让它个人化，并用于特定的目的)，或者仅仅使用像WebPack这样的模块。|2496787|另外，问自己这个问题，这些包裹真的会给你带来麻烦吗？|2496788|entityMap|0|LINK|mutability|MUTABLE|url|https://www.npmjs.com/package/express-validator|1|https://github.com/ctavan/express-validator/blob/master/package.json|2|https://webpack.js.org/^0|0|0|G|I|6|0|0|7|7|0|0|G|0|1C|2|5|7|0|0|0|M|0|38|7|0|E|6|0|1V|25|3O|6|1|0|0|Y|0|0|6|0|0|3|0|0|2T|0|0|E|0|0|2P|0|0|7|0|0|M|E|7|2|0|0|5|0|0|2U|0|0|Q|0^^$0|@$1|2|3|4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1X|8|@$D|1Y|E|1Z|F|G]|$D|20|E|21|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|22|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|23|8|@$D|24|E|25|F|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|26|8|@$D|27|E|28|F|G]]|9|@]|A|$]]|$1|O|3|P|5|6|7|29|8|@$D|2A|E|2B|F|G]]|9|@$D|2C|E|2D|1|2E]]|A|$]]|$1|Q|3|R|5|6|7|2F|8|@$D|2G|E|2H|F|G]]|9|@]|A|$]]|$1|S|3|T|5|6|7|2I|8|@$D|2J|E|2K|F|L]]|9|@]|A|$]]|$1|U|3|V|5|6|7|2L|8|@$D|2M|E|2N|F|G]]|9|@]|A|$]]|$1|W|3|X|5|6|7|2O|8|@$D|2P|E|2Q|F|G]]|9|@$D|2R|E|2S|1|2T]]|A|$]]|$1|Y|3|Z|5|6|7|2U|8|@$D|2V|E|2W|F|G]]|9|@]|A|$]]|$1|10|3|11|5|6|7|2X|8|@$D|2Y|E|2Z|F|G]]|9|@]|A|$]]|$1|12|3|13|5|6|7|30|8|@$D|31|E|32|F|G]]|9|@]|A|$]]|$1|14|3|15|5|6|7|33|8|@$D|34|E|35|F|G]]|9|@]|A|$]]|$1|16|3|17|5|6|7|36|8|@$D|37|E|38|F|G]]|9|@]|A|$]]|$1|18|3|19|5|6|7|39|8|@$D|3A|E|3B|F|G]]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|3C|8|@$D|3D|E|3E|F|G]]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|3F|8|@$D|3G|E|3H|F|G]]|9|@$D|3I|E|3J|1|3K]]|A|$]]|$1|1E|3|1F|5|6|7|3L|8|@$D|3M|E|3N|F|G]]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|3O|8|@$D|3P|E|3Q|F|G]]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|3R|8|@$D|3S|E|3T|F|G]]|9|@]|A|$]]|$1|1K|3|-4|5|6|7|3U|8|@]|9|@]|A|$]]]|1L|$1M|$5|1N|1O|1P|A|$1Q|1R]]|1S|$5|1N|1O|1P|A|$1Q|1T]]|1U|$5|1N|1O|1P|A|$1Q|1V]]]]

This is a very good question, there are a few things I want to point out.

The V8 engine, Node Modules(dependencies) and <code>require</code> ing them

Node.JS is built on V8 engine, which it's source code is C++. Which means that Node.JS's dependencies are fundamentally written in C++.

Now, when you're <code>require</code> ing a dependency, you are taking off code/functions from a c++ program or js library. That's how libraries/dependencies are made. 

Libraries have SO many functions that you will not use

For example, take a look at the <a href="https://www.npmjs.com/package/express-validator" rel="nofollow noreferrer"> express-validator module</a>. It has so many functions there. When you require the module, do you use all the functions it provides? The answer is no. People require packages like this just to use one single benefit of it, and all of the functions end up getting downloaded, which takes up unnecessary space. 

Think of the node dependencies that are made from other node dependencies as Interpreted Languages

Example: 
Javascript is written in C/C++ languages, those languages are written in Assembly. Think of it like a tree. You create new branches each time for more convenient usage and most importantly, to save time . It makes things faster. That is the similar situation for creating new dependencies, when people create a new dependency they use (<code>require</code>) the ones that already exist, instead of writing a whole C++ program or a JS script because that makes everything easier. 

Problem arises when requiring other NPMs for creating a new one

When the authors of the dependencies require other dependencies from here and there just to use a few (small amount) benefits of them, they end up downloading them all, (which they don't really care because they mostly do not worry about the size or they'd rather do this than explicitly writing a new dependency or a C++ addon) and this takes extra space. For example you can see the dependencies that express-validator module uses <a href="https://github.com/ctavan/express-validator/blob/master/package.json" rel="nofollow noreferrer">from 
this link.</a>

So, when you have big projects that use lots of dependencies you end up taking so much space for them.

Ways to solve this

Number 1

This requires some expert people on Node.JS. To reduce the amount of the downloaded packages, a professional Node.JS developer could go to the directories that modules are saved in, open the javascript files, take a look at their source code, and delete the functions that they will not use without changing the structure of the package.

Number 2 (Most likely not worth your time)

You could also create your own personal dependencies that are written in C++ or more preferably JS, which would literally take up the least space possible depending on the programmer but would take the most time inefficient time to reduce some size instead of doing work. (Note: Most dependencies are written in JS)

Number 3 (Common)

Instead of Using option number 2, you could implement <a href="https://webpack.js.org/" rel="nofollow noreferrer"> WebPack </a>.

Conclusion &amp;&amp; Note

So basically there is no running away from downloading all the node packages, but you could use the solution number 1 if you believe you can do it, which also have the possibility of screwing the whole intention of a dependency.(so make it personal and use it for specific purposes) or just make use of a module like WebPack.

Also, ask this question to yourself, do those packages really cause you a problem?

blocks|key|2533700|text|为几个kB项目交付数百个重达数百MB的包有什么意义？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|2533701|没有..。|unstyled|2533702|如果您打算将其提供给其他开发人员，只需使用gitignore+(或从共享包中删除)+node_modules或bower_components目录即可。开发人员只需根据需要再次安装依赖项;)|offset|length|style|CODE|2533703|如果它像HTML模板或类似的东西一样简单，节点很可能只是为了让您作为开发人员的生活更容易提供实时重新加载、编译/转换类型记录/babel/SCSS/SASS/LESS/Coffee.(清单继续;P+)等|2533704|在这种情况下，依赖关系很可能只是dev_dependencies，而在生产环境中根本不需要)+;)|2533705|此外，许多包都有独立的生产和开发依赖项，因此您只需要安装产品依赖项.|2533706|npm+install+--only=prod|code-block|syntax|javascript|2533707|如果您的项目在生产中确实需要很多项目，而且您真的想避免这种情况，只需花费一些时间并包含您的项目所需的css/js文件(这可能是一项艰巨的任务)。|2533708|更新|2533709|生产与默认安装|BOLD|2533710|大多数项目都有不同的开发和生产依赖性，|2533711|开发依赖项可能包括诸如SASS、类型记录等编译器、uglifier(小型化)、可能是像实时重新加载之类的东西。|2533712|其中，作为生产版本，将不会有那些缩小大小的node_modules目录。|2533713|**无node_modules**|2533714|在某些html模板类型的项目中，生产中可能不需要任何node_modules，因此跳过npm+install。|2533715|无法访问node_modules的|2533716|或者在某些情况下，当服务器在node_modules本身中存在时，可能会阻止对它的访问(因为不需要从前端访问这些服务器)。|2533717|entityMap^0|0|0|16|C|1J|G|0|0|0|0|0|0|0|0|7|0|0|0|L|C|0|3|C|0|Q|C|17|B|0|4|C|4|C|0|0|1P|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1J|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|1K|8|@$G|1L|H|1M|I|J]|$G|1N|H|1O|I|J]]|9|@]|A|$]]|$1|K|3|L|5|D|7|1P|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1Q|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|1R|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1S|8|@]|9|@]|A|$T|U]]|$1|V|3|W|5|D|7|1T|8|@]|9|@]|A|$]]|$1|X|3|Y|5|D|7|1U|8|@]|9|@]|A|$]]|$1|Z|3|10|5|D|7|1V|8|@$G|1W|H|1X|I|11]]|9|@]|A|$]]|$1|12|3|13|5|D|7|1Y|8|@]|9|@]|A|$]]|$1|14|3|15|5|D|7|1Z|8|@]|9|@]|A|$]]|$1|16|3|17|5|D|7|20|8|@$G|21|H|22|I|J]]|9|@]|A|$]]|$1|18|3|19|5|D|7|23|8|@$G|24|H|25|I|J]]|9|@]|A|$]]|$1|1A|3|1B|5|D|7|26|8|@$G|27|H|28|I|J]|$G|29|H|2A|I|J]]|9|@]|A|$]]|$1|1C|3|1D|5|D|7|2B|8|@$G|2C|H|2D|I|11]|$G|2E|H|2F|I|J]]|9|@]|A|$]]|$1|1E|3|1F|5|D|7|2G|8|@$G|2H|H|2I|I|11]]|9|@]|A|$]]|$1|1G|3|-4|5|D|7|2J|8|@]|9|@]|A|$]]]|1H|$]]

<blockquote>
 What is the point of delivering hundreds of packages weighing hundreds of MB for a few kB project.
</blockquote>

There isn't..

If you intend to provide it to other developers, just gitignore (or remove from shared package) <code>node_modules</code> or <code>bower_components</code> directories. Developers simply install dependencies again as required ;)

If it is something as simple as an HTML templates or similar stuff, node would most likely be there just for making your life as a developer easier providing live reload, compiling/transpiling typescript/babel/SCSS/SASS/LESS/Coffee... ( list goes on ;P ) etc.

And in that case dependencies would most likely only be dev_dependencies and won't be required at all in production environment ;)

Also many packages come with separate production and dev dependencies, So you just need to install production dependencies...

<pre><code>npm install --only=prod
</code></pre>

If your project does need many projects in production, and you really really wanna avoid that stuff, just spend some time and include css/js files your your project needs(this can be a laborious task).

<hr>

Update

Production vs default install

Most projects have different dev and production dependencies, 

Dev dependencies may include stuff like SASS, typescript etc. compilers, uglifiers (minification), maybe stuff like live reload etc.

Where as production version will not have those things reducing the size <code>node_modules</code> directory.

** No <code>node_modules</code>**

In some html template kind of projects, you may not need any <code>node_modules</code> in production, so you skip doing an <code>npm install</code>.

No access to <code>node_modules</code>

Or in some cases, when server that serves exists in node_modules itself, access to it may be blocked (coz there is no need to access these from frontend).

blocks|key|1204350|text|那些是什么?为什么他们会和我的包裹一起安装？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|1204351|依赖关系的存在是为了通过模块化来促进代码重用。|unstyled|1204352|..。我是否需要在生产中交付我的模板和数百个不必要的包？|1204353|人们不应该这么快就否定这种模块化。如果内联require并消除死代码，您将失去自动应用于代码的依赖项维护补丁的好处。你应该把这看作是一种汇编，因为.好吧..。这是汇编。|offset|length|style|CODE|1204354|尽管如此，如果您被授权以这种已编译形式重新分发所有依赖项，您会很高兴地了解到这些优化是由编译Javascript到Javascript的编译器执行的。闭包编译器，作为我无意中遇到的第一个例子，似乎执行了高级编译，这意味着您将得到死代码删除和函数内联。那似乎很有希望！|1204355|entityMap|0|LINK|mutability|MUTABLE|url|https://developers.google.com/closure/compiler/|1|https://developers.google.com/closure/compiler/docs/api-tutorial3^0|0|0|0|L|7|0|23|5|0|2T|4|1|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|10|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|11|8|@$I|12|J|13|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|14|8|@]|9|@$I|15|J|16|1|17]|$I|18|J|19|1|1A]]|A|$]]|$1|O|3|-4|5|D|7|1B|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]|W|$5|R|S|T|A|$U|X]]]]

<blockquote>
 What are those? Why did they get installed along with my package? 
</blockquote>

Dependencies exists to facilitate code reuse through modularity.

<blockquote>
 ... do I need to deliver my template in production with hundreds of unnecessary packages?
</blockquote>

One shouldn't be so quick to dismiss this modularity. If you inline your <code>require</code>s and eliminate dead code, you'll lose the benefit of maintenance patches for the dependencies automatically being applied to your code. You should see this as a form of compilation, because... well... it is compilation.

Nonetheless, if you're licensed to redistribute all of your dependencies in this compiled form, you'll be happy to learn those optimisations are performed by a compiler which compile Javascript to Javascript. <a href="https://developers.google.com/closure/compiler/" rel="nofollow noreferrer">The Closure Compiler</a>, as the first example I stumbled across, appears to perform <a href="https://developers.google.com/closure/compiler/docs/api-tutorial3" rel="nofollow noreferrer">advanced compilation</a>, which means you get dead code removal and function inlining... That seems promising!

blocks|key|2533803|text|然而，当您需要对所有npm+modules..so进行授权时，由于依赖关系，这会产生另一个副作用--当您有数百个npm模块时，这项工作也变得更加繁琐。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2533804|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This does however have another side effect when you are required to justify the licensing of all npm modules..so when you have hundreds of npm modules due to dependencies this effort also becomes a more cumbersome task

blocks|key|2533819|text|很老的问题，但我碰巧遇到了非常类似的情况，正如RA所指出的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2533820|我尝试使用node.js框架使用vscode，当我尝试使用npm+init+-y安装start+npm时，它产生了许多不同的依赖项。在我的例子中，在运行vscode之前添加到的是npm+init+-y扩展ESlint|2533821|卸载ESlint|unordered-list-item|2533822|重新启动vscode以应用该卸载|2533823|删除以前生成的package.json和node-modules文件夹|2533824|再次做npm+init+-y|2533825|这解决了我从这么多依赖项开始的问题。|2533826|entityMap^0|N|2|0|G|6|T|B|24|6|2H|B|2U|6|0|2|6|0|4|6|0|7|C|K|C|0|3|B|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|K|3|L|5|J|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|M|3|N|5|J|7|1E|8|@$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|O|3|P|5|J|7|1J|8|@$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1M|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1N|8|@]|D|@]|E|$]]]|T|$]]

Very old question but I happened to come across very similar situation just as <code>RA</code> pointed out.
I tried to work with node.js framework using <code>vscode</code> and the moment when I tried to install start npm using <code>npm init -y</code>, it generated so many different dependencies. In my case, it was <code>vscode</code> extension <code>ESlint</code> that I added to prior to running <code>npm init -y</code>
<ul>
<li>Uninstalling <code>ESlint</code></li>
<li>Restarted <code>vscode</code> to apply that uninstallation</li>
<li>removed previously generated <code>package.json</code> and <code>node-modules</code> folder</li>
<li>do <code>npm init -y</code> again</li>
</ul>
This solved my problem of starting out with so many dependencies.

I bought a HTML template recently, it contains many plugins placed inside <code>bower_components</code> directory and a <code>package.js</code> file inside. I wanted to install another package I liked, but decided to use <code>npm</code> for this purpose.

When I typed:

<code>npc install pnotify</code>

<code>node_modules</code> has been created containing about 900 directories with another packages.

What are those? Why did they get installed along with my package? I did some research and turned out that those are needed but really, do I need to deliver my template in production with hundreds of unnecessary packages?

npm installs many dependencies

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我最近买了一个HTML模板，它包含许多放在bower_components目录中的插件和一个package.js文件。我想安装另一个我喜欢的软件包，但决定为此目的使用npm。当我打字时：npc install pnotify已经创建了包含大约900个目录和另一个包的node_modules。那些是什么?为什么他们会和我...

问npm安装许多依赖项。
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问npm安装许多依赖项。EN