Zed Package Manager Learning Notes

You know, ZPM will improve a lot in the future, but now, let me talk about how it works: How to install, manage application packages, and how to develop application packages to extend Zed's functionality.
Let's start with installation and management.
installation and Management #

Installing the Zed application package is simple, and all you need is a zed (nonsense) and the URI address of the application package you want to install (more on the URI).
Want to see which apps are installed now? Run the Tools:Zpm:Installed packages command in the edit window, which opens a session that lists all of the application packages currently installed, where you can uninstall, update, update all application packages, and, of course, install new application packages. List with normal Zed file when the user interface, you can use the keyboard (move the cursor to the "button" and then press ENTER) or the mouse (the mouse directly click on a "button") operation. Note that Zed's preinstalled application package is not uninstalled (there is an uninstall option on the interface, but it doesn't work).
To install the new application package, click the "Install new" button. You can also run Tools:Zpm:Install (anywhere you can, without forcing to be sure to install the application package interface). Then, enter the application package URI. You can try a simple application package gh:zefhemel/sample-zed-package (we'll show you how to develop it later). After the installation is complete, you should have a new command, the My Test command, which pops up the Hello World dialog box.
Awesomeness.
Zed's current application package is decentralized, with no central libraries such as sublime or atom. But for the time being you can use Zed Wiki instead.
In-depth

Essentially, the application package simply provides a simple way to install some files into the configuration project. You can look at the/packages under the Configuration project (the tree structure is the most convenient: command-t/ctrl-t) folder where you can see some pre-installed application packages. By the time this article was written, the following patterns were distributed as Zed application packages:
JavaScript mode
JSON mode
JSON5 mode
PHP mode
CSS mode
JSX mode
to , there will be more built-in patterns migrating to the Zed application package, but the task is not light, so it will take some time.
If you open the/default.json file under your configuration project, you can see a packages key:

code is as follows	copy code
packages: [ & nbsp;   "Gh:zedapp/javascript-mode",     "Gh:zedapp/json-mode",      "Gh:zedapp/json5-mode",     "Gh:zedapp/php-mode",     "gh:zedapp/ Css-mode ",    " Gh:zedapp/jsx-mode "

Zed will ensure that the application packages listed here are installed and updated automatically. If you install an application package from your own, you can find it in your/user.json file.
So, where do these application packages come from? The URI of an application package can be a complete HTTP link, pointing to a directory containing a Package.json file. Of course, you can also use shortcuts. A shortcut Uri has GH: (GitHub) or BB: (bitbucket) prefix (for now). They will expand (for Gh:zedap/javascript-mode) into https://raw.githubusercontent.com/zedapp/javascript-mode/master/. ZPM to patch the Package.json and find a JSON file similar to the following:

code is as follows	copy code
{      "name": "JavaScript mode",     uri: "Gh:zedapp/javascript-mode",      "version": "0.2",     "description": "JavaScript mode for Zed",     "Files" : [         beautify-js.js,          "Beautify.js",         "Check.js",          "Index.js",         "Jshint.js"    ] }

The required keys are as follows:
URI: The URI must be consistent with the URI that people use to install your application (otherwise, you may not be in the wrong)
Name: Names of application packages displayed in the UI
Description: Descriptive content displayed in the UI
Version: As soon as you update this number, people who have installed your application will be able to upgrade them automatically (ZPM check updates every few hours)
Files: A list of relative paths to the file that makes up the application package (Package.json and Config.json are automatically included, you don't have to add them to the list yourself)
Each application package, in addition to the Package.json file, should have at least one Config.json file containing common Zed configurations, such as defining new commands, patterns, style themes, or anything else your application package provides. such as the configuration of this JavaScript pattern. Most of the rest of the files are just JavaScript files that implement the commands listed in the config file.
Develop your own Application pack #

Ready

The first thing you need to do is to save your configuration project to a local directory (instead of SYNCFS, which is the default location for Chrome version of Zed). The reason is that you may need to upload or push your application packages to places such as GitHub, so you need access to these files directly. In the chrome version, you can run Configuration:store in the local Folder command. If you are using a stand-alone version of Zed, under Linux, your configuration file is saved under ~/.config/zed/config,mac and stored in ~/library/application support/zed/config. If you want to save the configuration file somewhere else, use the Configuration:set Configuration directory command. I personally save my configuration in my Dropbox folder.
Think about where to host your application package #

I suggest that you create a common code base for your application package on Gihub or BitBucket. In this article, we will take an example of a GitHub library called Sample-zed-package that I have hosted on my Zefhemel GitHub account.
Create Application Package #

The configuration project has a few commands designed for developers to get you started quickly. Run command Tools:Zpm:Create Package. This will pop up the dialog box asking you to enter the URI of the application package. We also enter gh:zefhemel/sample-zed-package (replace your Ningiku name).
So we created two files in the/packages/gh/zefhemel/sample-zed-package/directory, Package.json and Config.json. The Package.json file is opened by default. Please modify its default values according to your meaning, for example:

The code is as follows	Copy Code
{ "Name": "My A-Zed Package", "uri": "Gh:zefhemel/sample-zed-package", "Version": "1.0", "description": "A useful new package", "Files": [] }

Next, let us Open the same directory of the Config.json file (tips: Press COMMAND-E/CTRL-E to call up Goto, press the space bar to complete the current directory full path, and then select Config.json).
In our case, just define a command sample:

The code is as follows	Copy Code
Commands: { "My Test Command": { Scripturl: "./command.js" } } }

Next, let's create a new/packages/gh/zefhemel/sample-zed-package/command.js (also using goto tips):

The code is as follows	Copy Code
var UI = require ("Zed/ui"); Module.exports = function (info) { Return Ui.prompt ("Hello world!"); };

As you can see, Zed's commands are modular in COMMONJS style. It exports a function that receives a variable (info). Depending on your configuration, variables can contain useful information about the execution environment of the command. Zed keeps adding APIs that allow you to interact with the editor, all of which can be obtained through the Require zed/* module. You can see what's in the/api/zed directory in your configuration project. I must admit that the documentation for these APIs is still poorly documented, so it is advisable to look at more examples before the documentation is complete. For example, the configuration project: all installed application packages, patterns, theme styles, and various command codes are there, as you can see. If you have specific questions, please join Zed Google Group to ask!
To test our newly created project, we need to add it to the application package list in/user.json:

The code is as follows	Copy Code
Packages: [ "Gh:zefhemel/sample-zed-package" ]

Your configuration is automatically overloaded, so the new command is already available. You can run the My Test command command to verify that. If not, you can use the Configuration:reload command to force your configuration to overload. If you change the Config.json file, you will need to force the overload every time. Another command you will often use is sandbox:reset, which will ensure that your JavaScript code is overloaded the next time it is invoked.
Publish your Application Pack #

Before publishing your application package, we need to remember one important thing: Update our Package.json file and introduce all the rest of the files (excluding Package.json and Config.json). The good news is that Zed offers a handy command: switch to your Package.json file, and then execute Tools:Zpm:Update package.json files List. This command automatically scans your project and then updates the Package.json file to refer to the Command.js file.
Zed is all about that. Anyway, the only thing left to do is to turn our application package directory into a git directory, commit all the files, and push to GitHub.
First, open the Command window, CD to your zed configuration directory, and then CD to our application Package directory:

The code is as follows	Copy Code
$ CD Packages/gh/zefhemel/sample-zed-package Initialize a git library under the directory, and then add all the files and commit: $ git init $ git Add * $ git commit-m "Initial checkin" Configure the GitHub library we created earlier to be remote and push the code up. My situation: $ git Remote add Origin git@github.com:zefhemel/sample-zed-package.git $ Git push-u Origin Master

That's it.
Test your Application Pack #

Before we tell all our friends, we also need to test the application package. I'm usually prepared with a different zed (I either developed it with a standalone version, the chrome version is tested or reversed, or it's using Zed, which is installed on the Chrome Canary). Alternatively, you can switch your zed configuration to a new, clean directory, and then switch back. The goal is simply to prepare a zed that has not yet installed your application package. You can even change a computer (for example, your Chromebook).
To install your application package, run the Tools:Zpm:Install command at your clean version of Zed and enter the application package URI. If all goes well, your command should already be available. In addition to executing the Tools:Zpm:Install command, you can also manually update the packages list in the configuration to increase your application package URI. The effect is the same.
Work? Congratulations, please be sure to add your application package to our wiki page.
Development and Debugging Tips #

In order to develop the Zed application package, you'd better consider the configuration project as a development environment. I usually add new modes and commands to the/user.json file first, and then migrate to the application package if there is no problem.
Logging: Each project has a Zed::log file that lists the hints, errors and warnings, and sandbox code given by Zed. If your application package or script does not work properly, please check Zed::log to find out where it may have gone wrong. You can also debug using Console.log in your JavaScript, and their output will be displayed in Zed::log ([Sandbox] prefix).
Overload/reboot: In a sandbox run, Zed Strictly distinguishes all application packages and extension code from the editor itself so that you can edit the application package and test the results immediately without restarting or reopening the editor window. Just you need to overload your profile (Config.json) so you can run the configuration:reload command. If you modify your JavaScript code and run the Sandbox:reset command, Zed reloads the files and you can see the changes.
Protip: If you're going to do a lot of Zed application package development work, it's best to bind the Configuration:reload and Sandbox:reset commands to the key combination. For example, I am in my/user.json file:

The code is as follows	Copy Code
Keys: { "Sandbox:reset": "Ctrl-shift-s", "Configuration:reload": "Ctrl-alt-shift-s" }

Problems:
If the configuration has been overloaded after you add the packages key to your application package to the/user.json file, one possible reason is that the URI defined in Package.json does not match the path of the application package. In other words, if your application package URI is Gh:abc/def, your package.json must be placed in the/packages/gh/abc/def/package.json position. If not, the problem with the loop will appear.
If you see 404 errors in Zed::log When you install or run the application package, the problem is likely to be in the files list in your Package.json file. If 404 appears when you install the application package, make sure that the files listed in Package.json are present. If 404 appears in the test after installation, make sure that the files that Zed claims are not found appear under the files key in your Package.json file.
That's good! Let's see what you can develop!