我想马上保留一点，即本文不适合那些进行前端开发主要活动的人员。 这篇文章面向急需固定Web UI的后端开发人员或仅对新领域感兴趣的后端开发人员，以及全栈开发人员。
因此，让我们继续解决这个问题。 我记得
有一篇文章 ，而且在哈勃（Habr）的开放空间中，还有更多类似的文章。 它们全都以喜剧形式呈现，但是正如他们所说的“在每个笑话中都有一点道理”，而在这里甚至没有一点……但这是一个问题，所有这些框架有多么有用？
我想提出的问题主要是关于组装。 正是在这个阶段，js社区提供了数量惊人的工具，对这些工具的需求一点也不明显。 例如，社区提供了使用模块的各种选项，这在当时是很有意义的，但目前，所有现代浏览器（甚至边缘浏览器）都支持
导入 /
导出规范。 由于我们前面提到过，我们没有理由使用旧库，因此我们将研究导入/导出规范。 但是我们真正需要的是某种与依赖项相关的工作。
我将做一点题外话，说明在示例中将为前端本身使用的技术的选择。 为了不深入研究各种各样的框架，让我们从一个出色的
标准着手。 因此，一切都变得非常简单，没有虚拟DOM，有Web组件。 可以完成，但是仍然是js。 如果我们决定摆脱
纯 js，那么我们将不得不以某种方式解决基础架构问题，摆脱锅炉代码等。 换句话说，让您的自行车有点...为了不这样做，我想采取一些已经完成且质量足够的事情。 因此，我的选择落在
Polymer上
-Google的框架，该框架将Web组件推向了标准。
回到组装。 你们中的许多人（无论如何都是Java开发人员）都习惯于使用诸如maven和gradle之类的工具，并且您可能设法发现他们在资源操纵方面做得很好（对于maven，这当然要差一些，但是对于gradle而言，根本没有问题）任何东西）。 前端社区为我们提供了npm，需要它的nodeJ，但这还不够，webpack还是最重要的。 他们仍然必须理解并交付给每个开发人员。 嗯...我只想缩小存储库，构建gradlew并开始工作，所以让我们停在通常的gradle上。
当然，我们根本不能没有npm，至少我们需要一个可以从其中获取js库的仓库，而npm可以提供它，但是该实用程序是可选的。 您可以找到诸如此类的一些好的解决方案，但是它们总是下载nodeJ并运行npm任务。 一个选项，但是我想在与存储库等交互之前，尽量减少与npm的通信。 作为解决方案，编写自己的gradle插件。 尽管为gradle编写插件非常简单，但是由于为npm存储库指定版本的选项多种多样，因此任务有些复杂。 幸运的是，这里有明确的
文档 。
因此，让我们编写一个gradle脚本来加载依赖项。 kotlin dsl使用它的原因是，重写groovy dsl足够简单，但是相反，如果没有以前的经验，则需要时间。
repositories { mavenLocal() jcenter() } dependencies { classpath("com.github.artfable.gradle:gradle-npm-repository-plugin:0.0.3") } apply(plugin = "artfable.npm") configure<GradleNpmRepositoryExtension> { output = "$projectDir/src/libs/" dependencies = mapOf( Pair("@polymer/polymer", "3.0.5"), Pair("@polymer/app-layout", "3.0.1"), Pair("@polymer/paper-toolbar", "3.0.1"), Pair("@polymer/paper-icon-button", "3.0.1"), Pair("@polymer/iron-icons", "3.0.1"), Pair("@webcomponents/webcomponentsjs", "2.1.3") ) }
这个
插件将为我们添加
npmLoad 。 为了让IDE分组更好，请在一个分组中对其进行定义
tasks["npmLoad"].group = "frontend"
太好了，您可以尝试为我们的前端编写代码。 默认情况下，内置的Intellij服务器会告诉您“
不允许的方法”正在尝试通过导入连接脚本。 为避免这种情况，请选中“
允许使用请求”复选框。 （在最新版本中，没有它就可以使用）。
让我们尝试从现在开始，然后...仍然没有任何效果。 聚合物组分内部的依赖性下降。 事实是，许多js库在导入某种导入式编译器（如babel）的情况下都会进行导入。 这样的导入看起来像这样：
import '@polymer/polymer/polymer-legacy.js';
此语法导入不正确，因为对于浏览器，路径应仅以“ /”、“./”或“ ../”开头。 此外，以这种形式不能将其视为相对的或绝对的，因为此处的计算是从根目录开始的库目录的开始。 因此，需要固定这些路径，并且为了自己避免这样做，可以使用准备好的
插件 。
根据
classpath("com.github.artfable.gradle:gradle-js-import-fix-plugin:0.0.1")
apply(plugin = "artfable.js.import.fix") configure<GradleJsImportFixExtension> { directory = "$projectDir/src/libs" }
任务
jsImportFix将被
添加 ，它将按顺序将所有导入。
就像这样，无需处理大量新工具，您就可以放在一起。 但是，让我们再次看一下样式问题。 坦白地说，Web组件摆脱了样板，并且标准中已经包含了CSS中的变量，这提供了许多可能性，因此不再需要诸如sass之类的东西。 但是突然之间，例如，您非常喜欢
自举 ，并想要基于它进行设计。
找到任何可以在此主题上构建的插件都是没有问题的，基本上，它们都以
libsass为基础，并且java-
jsass中有一个包装器。 每个人（至少在我考虑它们的时候）唯一的问题是复制依赖文件。
一个例子：
档案a：
@import “b”; @import “c”;
_B和_c文件：
@import “d”;
结果，我们从_c文件中获取了两个相同的主块。 如果将
导入器添加到jsass，则api允许，您可以非常简单地对其进行修复。 因此，实际上，我还是
在这里做出决定（如果没有这样的要求，那么最好使用其他解决方案）。
将npm依赖项添加到列表中
Pair("bootstrap", "4.1.3")
插件依赖
classpath("com.github.artfable.gradle:gradle-sass-plugin:0.0.1")
apply(plugin = "artfable.sass") configure<GradleLibsassPluginExtension> { group(delegateClosureOf<GradleLibsassPluginGroup> { sourceDir = "src/sass" outputDir = "src/css" } as Closure<Any>) } tasks.create("processResources")
如果未连接Java插件，则必须创建processResources伪造任务（我们在这里不需要）。 这当然是一个缺陷，那么我一定会解决。
请注意，生成的css文件一定不能连接到
head ，因为从那以后它在组件内部将是不可见的，而是直接进入组件本身的模板中。
最后一步是稍微修改脚本，以获取通常的
构建目录，并带有可以部署到生产中的现成项目。
完整的代码已上传到github（稍后可能需要迁移到gitlab ...）。
我希望基本思路清楚，然后可以添加任何您喜欢的内容。 感谢您的阅读。