命令行 修复系统

by Manuel Vila

通过曼努埃尔·维拉(Manuel Vila)

让我们修复旧的命令行 (Let’s fix the good old command line)

Although we have beautiful graphical user interfaces, it seems that we are using more and more command-line tools. And while many of them are really good, I think they could be even better if they were based on more modern foundations.

尽管我们拥有漂亮的图形用户界面，但似乎我们正在使用越来越多的命令行工具。 尽管其中许多确实很好，但我认为，如果它们基于更现代的基础，它们甚至会更好。

To show the issue, I will consider two essential characteristics: customizability and usability. And, by looking at some of the more popular tools, I will show how difficult it is to achieve both characteristics at the same time.

为了说明这个问题，我将考虑两个基本特征：可定制性和可用性。 并且，通过研究一些更流行的工具，我将展示同时实现这两个特征有多么困难。

I’m going to talk mainly about JavaScript tools, because it’s the environment I’m the most comfortable with. But the problem is similar regardless of the development environment.

我将主要讨论JavaScript工具，因为这是我最适应的环境。 但是无论开发环境如何，问题都是相似的。

创建React应用 (Create React App)

Create React App illustrates the case of a tool that is very easy to use but not very customizable. It brings together a set of tools, techniques, and best practices to start a modern web app in no time.

Create React App演示了一种非常易于使用但定制程度不高的工具的情况。 它汇集了一组工具，技术和最佳实践，可以立即启动现代Web应用程序。

In this respect, it is extremely valuable, but it is implemented like a black box. It’s hard to change something inside. Yes, there is an eject feature, but I don’t think this is a real solution. It’s trading one characteristic for another. The tool becomes more customizable but is no longer easy to use.

在这方面，它非常有价值，但实现起来却像黑匣子。 很难改变里面的东西。 是的，有eject功能，但是我认为这不是真正的解决方案。 它以一种特征换另一种。 该工具变得更具可定制性，但不再易于使用。

npm脚本和特定代码 (npm scripts and specific code)

Here, we have the greatest level of customizability, but usability is low. By writing npm scripts and specific code, it is possible to create any kind of builders, deployers, etc. But, this is not for everyone, and it’s a pretty laborious task. Putting together a set of tools using npm scripts (i.e., Bash) is not quite user-friendly, and writing code in JavaScript to configure and control tools through npm modules is somewhat cumbersome.

在这里，我们具有最大的可定制性，但是可用性很低。 通过编写npm脚本和特定的代码，可以创建任何类型的构建器，部署器等。但是，这并不适合每个人，这是一项非常艰巨的任务。 使用npm脚本(即Bash )将一组工具放在一起并不是很友好，并且用JavaScript编写代码以通过npm模块配置和控制工具有点麻烦。

的WebPack ， 一饮而尽 ， 无服务器架构等。 (webpack, gulp, Serverless Framework, etc.)

Finally, here are some tools that are both quite customizable and easy to use. But, the price to pay is high. We have to deal with their plugin system, or, rather, the fact that there is such a system.

最后，这是一些非常可定制且易于使用的工具。 但是，要付出的代价很高。 我们必须处理他们的插件系统，或者说，有这样一个系统。

The problem is that each time a tool offers a plugin system, it creates a new ecosystem. The result is that instead of having a global ecosystem of tools, we end up with a proliferation of ecosystems that operate in silos. So, many plugins are doing the same thing but for different ecosystems (e.g., awesome-typescript-loader, gulp-typescript, serverless-plugin-typescript, etc.). What a waste of time.

问题在于，每次工具提供插件系统时，都会创建一个新的生态系统。 结果是，我们没有了一个全球性的工具生态系统，而最终导致了孤岛运作的生态系统激增。 因此，许多插件在针对不同的生态系统执行相同的操作(例如， awesome-typescript-loader ， gulp-typescript ， serverless-plugin-typescript等)。 真浪费时间。

Very often, when a tool implements a plugin system, it is an indicator that something is going wrong. It is trying to solve a problem that should probably be addressed at a lower level.

通常，当工具实现插件系统时，这表明出现了问题。 它正在尝试解决可能应该在较低级别解决的问题。

* nix，Bash等 (*nix, Bash, etc.)

Don’t get me wrong. All the tools I mentioned earlier are fantastic. Given the foundations on which they are based, they are doing great. I mean they have to struggle with Unix-like systems and shells such as Bash. Can you believe that all our modern tools are based on foundations that have barely changed in nearly half a century?

不要误会我的意思。 我前面提到的所有工具都很棒。 有了它们所基于的基础，它们就做得很好。 我的意思是，他们有奋斗类Unix系统和外壳，如猛砸 。 您是否可以相信我们所有的现代工具都基于近半个世纪以来几乎没有变化的基础？

Typically, when we work on a project, we use several tools such as (in the case of a modern web project), a dependency manager, a transpiler, a bundler, and so on. So we need a way to install, configure, and compose all these things. Unfortunately, our good old command line is not very good at this.

通常，当我们处理项目时，我们使用多种工具，例如(对于现代Web项目而言)，依赖项管理器，翻译器，捆绑器等。 因此，我们需要一种安装，配置和组合所有这些东西的方法。 不幸的是，我们良好的旧命令行在这方面不是很好。

We use configuration files based on many different formats to configure our tools. We communicate with them through an array of strings (argv). To compose them, there is, well, Bash… Finally, since typical shells can’t handle several versions of the same tool, managing our development environment is painful when we have to deal with many projects.

我们使用基于许多不同格式的配置文件来配置我们的工具。 我们通过字符串数组( argv )与他们进行通信。 组成它们的地方是Bash，最后，由于典型的Shell无法处理同一工具的多个版本，因此在必须处理许多项目时，管理我们的开发环境非常麻烦。

Seriously, we cannot say that it’s user-friendly. Sure, we have great programming languages and rich libraries. The tools are beautiful inside, but outside, they are ugly. When it comes to configuring, composing and executing them, it’s not cool, and because of that, we end up with the customizability-usability dilemma.

认真地说，我们不能说它是用户友好的。 当然，我们拥有出色的编程语言和丰富的库。 里面的工具很漂亮，但是外面却很丑陋。 当涉及到配置，组成和执行它们时，这并不酷，因此，我们最终遇到了可定制性-可用性难题。

您好，“资源” (Hello, “resources”)

I worked full time for a year trying to solve this problem, and I ended up with what I call a “resource”. Also, as a proof of concept, I built “Run,” a resource runtime.

为了解决这个问题，我全职工作了一年，最后得到了所谓的“ 资源 ”。 另外，作为概念证明，我构建了资源运行库“ Run ”。

So, what’s a resource for? Basically, a resource adds an object-oriented interface to the tools, making them easier to use both from the command line and, programmatically, from other tools.

那么，什么是资源？ 基本上，资源会向工具添加面向对象的界面，从而使它们更易于从命令行以及从其他工具中以编程方式使用。

If you create a tool, you can wrap it into a resource to improve its usability and save a lot of development time. First, since Run installs tools automatically, the installation problem disappears. Then, given that users configure tools using resources, you don’t need to manage configuration files. Finally, you no longer need to implement a command-line interface. Run provides it for you.

如果创建工具，则可以将其包装到资源中以提高其可用性并节省大量开发时间。 首先，由于运行自动安装工具，因此安装问题消失了。 然后，假设用户使用资源来配置工具，则无需管理配置文件。 最后，您不再需要实现命令行界面。 运行为您提供了它。

If you are an end developer, and you are working on an application, website, backend, and so on, you can use a resource to reference the tools your project needs, and specify their configuration. Then, since your development environment is defined in a single file, your project is super easy to transport and share. Just grab the resource and you are all set. Also, since your resource consumes tools that are themselves resources, everything becomes extremely easy to configure, compose, and use.

如果您是最终开发人员，并且正在开发应用程序，网站，后端等，则可以使用资源来引用项目所需的工具并指定其配置。 然后，由于您的开发环境是在单个文件中定义的，因此您的项目非常易于传输和共享。 只需获取资源即可，一切就绪。 而且，由于您的资源消耗的工具本身就是资源，因此一切都变得非常易于配置，组成和使用。

它是什么样子的？ (What does it look like?)

A resource is a JSON or YAML document allowing you to specify the following:

资源是JSON或YAML文档，允许您指定以下内容：

• The tools that the resource consumes (by inheriting or composing them)资源消耗的工具(通过继承或组合)
• A set of attributes (to configure the tools)一组属性(用于配置工具)
• A set of methods (to add custom behaviors)一组方法(添加自定义行为)

For example, to build a website, you can start with something like this:

例如，要建立一个网站，您可以从以下内容开始：

{  "@import": "aws/s3-hosted-website#^0.1.0"}

Then, by invoking Run without any argument:

然后，通过调用不带任何参数的Run：

run

You get an auto-generated help reflecting the content of your resource:

您将获得一个自动生成的帮助，该帮助反映了资源的内容：

Because the resource imports "aws/s3-hosted-website", it inherits a number of attributes and methods. Let’s specify some attributes:

由于资源导入"aws/s3-hosted-website" ，因此它继承了许多属性和方法。 让我们指定一些属性：

{  "@import": "aws/s3-hosted-website#^0.1.0",  "domainName": "www.example.com",  "contentDirectory": "./content"}

Finally, let’s invoke the deploy method:

最后，让我们调用deploy方法：

run deploy

Voila! Your website is online. What about this "aws/s3-hosted-website#^0.1.0" thing? This is a reference to a resource that implements a tool for managing static websites hosted on AWS. And, to make it easier to use, it is stored in a resource directory.

瞧！ 您的网站在线。 这个"aws/s3-hosted-website#^0.1.0"怎么办？ 这是对资源的引用，该资源实现了用于管理托管在AWS上的静态网站的工具。 并且，为了使其更易于使用，它存储在资源目录中 。

I have played with resources pretty intensely for months, and really, it seems that the customizability-usability dilemma is solved. For example, here is a resource for a more realistic website including npm dependencies (without package.json file!) and a build method that runs a transpiler, a bundler, and a file copier:

几个月来我一直在紧张地使用资源，实际上，似乎可定制性-可用性难题已得到解决。 例如，以下是一个更实际的网站的资源，包括npm依赖项(没有package.json文件！)以及运行翻译器，捆绑器和文件复印机的build方法：

{  "@import": ["aws/s3-hosted-website#^0.1.0", "js/resource#^0.1.0"],  "domainName": "www.example.com",  "contentDirectory": "./build",  "dependencies": {    "color": "^3.0.0",    "lodash": "^4.17.4"  },  "build": {    "@type": "method",    "@run": ["transpiler run", "bundler run", "copier run"]  },  "transpiler": {    "@import": "js/transpiler#^0.1.0",    "source": "./src",    "destination": "./dist",    "targets": {"chrome": "41", "safari": "10", "firefox": "50"},    "format": "esm"  },  "bundler": {    "@import": "js/bundler#^0.1.0",    "entry": "./dist/index.js",    "output": "./build/bundle.js",    "target": "browser",    "format": "iife"  },  "copier": {    "@import": "tool/file-copier#^0.1.0",    "sourceDirectory": "./",    "destinationDirectory": "./build",    "files": ["./index.html", "./images"]  }}

Pretty easy, don’t you think? If you are lost, Run’s auto-generated help is your guide. For example, to find out more about the bundler, just invoke:

很简单，你不觉得吗？ 如果您迷路了，Run的自动生成的帮助将作为您的指南。 例如，要查找有关捆绑程序的更多信息，只需调用：

run bundler

You should see something like this:

您应该会看到以下内容：

结论 (Conclusion)

I’m not saying that the resource concept is the Holy Grail, but it’s the best I have found so far, and it’s a work in progress. Specifications are not stable yet; everything can change, even the denomination “resource” can change.

我并不是说资源概念是圣杯，但这是我到目前为止发现的最好的东西，而且它还在进行中。 规格还不稳定。 一切都会发生变化，甚至“资源”面额也会发生变化。

To find out more about the current state of Run and resources, you can have a look at the documentation and the GitHub repo.

要了解有关Run和资源当前状态的更多信息，可以查看文档和GitHub repo 。

So, what do you guys think? Is it just me having a problem with the command line? Or is it something that needs to be fixed? And if so, do you believe this resource concept is a step in the right direction?

那么，你们怎么看？ 只是我在命令行方面遇到问题吗？ 还是需要修复的东西？ 如果是这样，您是否认为此资源概念是朝正确方向迈出的一步？

翻译自: https://www.freecodecamp.org/news/lets-fix-the-good-old-command-line-b6eaa1f9c040/

命令行 修复系统