首先：这不是关于如何将NPM软件包用作Composer软件包的依赖关系的问题。这不是问题：直接使用NPM或composer插件即可解决。
假设我们将NPM软件包作为Composer软件包的依赖项加载（使用create-package），我们大致得到以下结构：
Root
+-- node_modules
| +-- our_npm_package
| +-- assets
| | +-- our.css
| +-- js
| +-- bundle.js
+-- vendor
| +-- our
| +-- package
+-- src
+-- tests
| composer.json
| package.json
| index.php
NPM软件包包含一些Web资产（JS，CSS，图像）。我们可以使用Browserify将其捆绑在一起，而只需在我们的index.php中使用bundle.js即可。但是我认为问题在于这样做是不好的方法。Browserify应该只捆绑JS，而不要使用CSS和图像。通过JS向浏览器提供CSS确实是对技术的错误使用：浏览器完全有能力自行加载CSS。这样，它就可以在禁用JS的浏览器中使用。关于图像的故事也一样：浏览器无需JS即可加载和显示它们。
因此，我得出结论，Browserify（我应该说很棒的包）仅应用于JS，它会产生不错的bundle.js，我们可以从index.php调用
这是问题的核心：如何在我们基于Composer的PHP软件包中正确引用这些基于NPM的资产？当然我们可以使用：
<link rel="stylesheet" type="text/css" href="/node_modules/our_npm_package/assets/our.css">
但这很丑陋而且不可靠。我真的希望它是：
<link rel="stylesheet" type="text/css" href="/css/our.css">
bundle.js也是如此。我不想拥有：
<script src="/node_modules/our_npm_package/js/bundle.js"></script>
反而
<script src="/js/bundle.js"></script>
许多人只是制作脚本，这些脚本在根文件夹中创建css和js文件夹，然后从NPM软件包中挑选资产。工程，但仍然丑陋。
有些人（尤其是使用框架的人）走得更远，并使用了某种可自动复制的composer插件。在这种情况下，他们在作曲家软件包中指定想要的资产。比单纯复制更好，但仍然不是很好。
我真正想要拥有的是以某种方式在NPM包中声明资产。然后使用Composer插件/脚本将其定位在NPM软件包中，并进行符号链接/将其复制到PHP代码应使用的位置。最重要的是，确保PHP所需的所有资产均真实存在。
我现在正为此目的编写作曲家插件，但我不想重新发明轮子。当然，我不是唯一一个面临着缝合Composer PHP / NPM JS问题的人，我希望这个问题已经得到适当解决。我过去三天在谷歌上搜索高低，找不到任何合适的东西。
您能告诉我有解决此问题的简单方法吗？可以将单个作曲家插件视为答案。
我已经制作了一个使用ext-mysqli的作曲家软件包“ foo”。在我的开发框中，存在mysqli扩展，因此我对该程序包的所有测试均成功完成，没有任何问题。但是，如果此程序包将落在没有安装mysqli扩展程序的盒子上，那么它将失败。Composer通过在“ require”，“ require-dev”和“ suggest”部分中允许“ ext- *”来解决此问题。但是，程序包开发人员应记住实际上要放入这些依赖项。显然，在发布所有未使用的扩展名都列为依赖项的程序包之前，没有什么可以阻止开发人员（或至少发出警告）。
借助当今可用的众多扩展，可以很容易地忽略这些依赖关系，尤其是当它们总是对用于开发特定程序包的dev box感到满意时，因此没有本地测试可以揭示它们的缺失。
是否有任何工具可以检查composer软件包以查看其是否使用了特定扩展名，并警告是否在composer.json中未实际列出使用的扩展名？