DEV Community: Zhe Li

Test for uploading images to Imgur in VS Code

Zhe Li — Mon, 07 Oct 2019 17:24:20 +0000

You can upload images to Imgur using DEV Community extension for Visual Studio Code now!

Write Posts in DEV Community using Visual Studio Code

Zhe Li — Thu, 03 Oct 2019 11:00:34 +0000

DEV Community is one of the most famous platform for developers to share great ideas. Thanks to DEV API, I made an extension to make it possible to write posts using Visual Studio Code.

In this article, you will learn how to use DEV Community extension for Visual Studio Code to write posts in DEV Community using Visual Studio Code.

Prerequisites

To get started, you need install Visual Studio Code. For better user experience, you can also install one or more markdown extensions for Visual Studio Code.

Install the DEV Community extension

In Visual Studio Code, open Extensions and search for dev.to.
Click Install to install the extension.
Restart Visual Studio Code and select DEV icon on the activity bar.

Sign In DEV Community Account

To write posts you need to sign in your DEV Community account first.

Click Create API key in DEV COMMUNITY: POSTS view to open DEV Community account dashboard in browser. Input vscode in description inputbox then click Generate API key button:
Copy the generated API key:
Back to Visual Studio Code, and click Sign in, paste API key:
You can see all your posts after signed in:

Edit or Write A New Post

To edit a post, click its title in post list to open in Visual Studio Code:
Press Ctrl + S to save your changes.
Click the Plus icon to create a new post:

Updated on 2019/10/23

You can use Code Spell Checker for spell check. To make Code Spell Checker work with DEV Community extension, you need add devto to Code Spell Checker allowed schemas:

Click File - Preferences - Settings to open Visual Studio Code settings page.

Search Allowed Schemas, click Add Item button to add devto into the list:

Preview and View Online

Visual Studio Code has built-in support for markdown preview, you can press Ctrl + K then press V (Ctrl + K V) to preview locally.

To published post, you can also right click its title in the post list to select View online to view the post in browser:

Publish A Post

To publish a post you can do one of the followings:

Change publish value to true in post yaml properties at top of the content, and save the post.
Right click the post in post list and select Publish post:

Insert Images

Like any markdown, you can insert online images like following:

![description](image-url)

Updated on 2019/10/8

From v0.0.11, the extension uploads images to Imgur by default. If you would like to upload to GitHub instead, press Ctrl + Shift + P and execute DEV Community: Update GitHub personal access token to configure GitHub token, and the extension will upload images to your GitHub repository then.

The DEV Community extension can help you to quickly upload images to GitHub and insert the code to your current post.

Open browser and go to https://github.com/settings/tokens/new.
Input vscode in note inputbox, check repo scope and click Generate token button:
Copy the generated token.
Click Upload images at bottom left corner of Visual Studio Code:

From v0.0.11, you need set GitHub token by executing DEV Community: Update GitHub personal access token command. Or the image will be uploaded to Imgur. See step 7.
Select the image you would like to upload, and the extension starts to upload the image to GitHub:
After upload complete, the code will insert to your current post automatically:
To change or remove GitHub token, press Ctrl + Shift + P, and execute DEV Community: Update GitHub personal access token and DEV Community: Remove GitHub personal access token:

Feedback and Contribute

DEV Community extension for Visual Studio Code is published under MIT license. You can find its source code from https://github.com/Sneezry/vscode-devto. This extension is still in preview, and its functionality may be limited. If you have any feedback, welcome to open a ticket at https://github.com/Sneezry/vscode-devto/issues (GitHub account required).

Hello World

Zhe Li — Thu, 03 Oct 2019 08:54:20 +0000

Hello from VS Code!

test

Build Desktop Apps with Node and Web Tech on VS Code Platform

Zhe Li — Mon, 27 May 2019 08:13:26 +0000

Build desktop apps with Node and web is very cool, however, Electron is a bit heavy. VS Code, one of the most popular editors, is the program I use every day. It is built with Electron. Can I run apps written with Node and web on its platform without install the runtime again? After some attempts, yes! I did it!

I made a VS Code extension that provides a gallery to show and launch such an app. You can install it from https://marketplace.visualstudio.com/items?itemName=sneezry.vscode-toolkit.

The extension is at its very early stage, and it's just for to verify my idea.

After install the extension, you can find a green beaker at bottom left corner of VS Code window, click it to open the app gallery.

In the gallery, you can see an app called Installer has already been installed. Click it and select any .tka (Toolkit App) to install.

Here's a sample Toolkit App you can download and have a try: https://github.com/Sneezry/cpu.tka/releases.

This sample app with show CPU usage on your machine.

How to write your own app? It's very simple!

The first thing is to create package.json, in the file to define displayName, icon, main and view. displayName is the text shows in the gallery, and icon is the relative path of the app icon. main is the entry file of the app, index.js for example. You need always declare a main function and export it in the entry file:

exports.main = function(webview) {
  // do something
}

The main function will be called when launch the app. webview is the context of the web interface. You can call webview.send(data) to send data to web.

view is the root path of web. index.html in the web root path will be open when the app launches.

On the web side, you can call any export Node function with a built-in NodeJS object.

For example, in the entry file, we have exported a function called foo:

exports.main = function(webview) {}

exports.foo = function() {
  // do something
  return data;
}

And you can call it in web like this:

const data = await NodeJS.foo();

All NodeJS functions are async in the web, no matter how you declare it on Node side.

If you want to receive data sent from Node on web side, declare a function call messager, and data sent by webview.send will pass to this function.

function messager(data) {
  // do something
}

Here's the data flow between Node and web:

+--------------+                     +--------------------+
| Node         |                     | Web                |
|              |                     |                    |
| webview.send ----------------------> messager(data)     |
|              |                     |                    |
| exports.foo  <---------------------- await NodeJS.foo() |
|              |                     |                    |
+--------------+                     +--------------------+

Also, you can install any node module in your app.

After all, zip your app and rename it to .tka.

Still have trouble to make it? See the sample app code: https://github.com/Sneezry/cpu.tka.

Enjoy!

How to Speed Up Your VS Code Extension - Not Only Webpack

Zhe Li — Thu, 02 May 2019 20:40:59 +0000

Introduction

Extensions let users add language, debuggers, and tools to VS Code to support their development workflow. VS Code has rich extensibility model which lets extension access to UI and contribute functionality.

Generally, more than one extension would be installed in VS Code, so as an extension developer, we should always care about performance of the extension to avoid slowing down other extensions or even the main process of VS Code.

Some rules we should follow when develop an extension:

Avoid using sync methods. sync methods would block the entire Node process till they return. Instead, you should use async/await as much as possible. If you find it hard to replace sync methods with async, consider to make a refactoring.
Only require what you need. Some dependencies may be very large, lodash for an example. Usually, we do not need all methods of lodash, and require the entire lodash library doesn't make sense. Every method of lodash has a standalone module, and you can require the part only you need.
Regard activating rule seriously. In most case, your extension may have no need to activate. Do not use * as activating rule. If your extension really needs always to activate to listen some events, consider to execute the main code within a setTimeout to act as a low priority job.
Load modules on demand. Using import ... from ... is a common way to require modules, however, it may be not a good way sometimes. For example, a module called request-promise may cost too much time to load (1 to 2 seconds on my side), but only when some conditions are met we may need to fetch remote resources, such as local cache is expired.

The first three rules mentioned above are followed by many developers. In this article, we will discuss about a way to load modules on demand, which should meet the habits we write TS or JS to import modules, and require as little cost to change existing code as possible.

Load Modules on Demand

Meet the habits

Commonly, we use import statement to load modules on top of the script as code shows below:

import * as os from 'os';

Node loads the specific module synchronously as soon as we import it, and blocks rest code behind.

What we need is a new method, called impor for example, to import module without loading it:

const osModule = impor('os'); // osModule is unaccessible as os module is not loaded yet

To reach this target, we need to use Proxy. The Proxy object is used to define custom behavior for fundamental operations.

We can customize get method to load the module only when it is called.

get: (_, key, reciver) => {
    if (!mod) {
        mod = require(id);
    }
    return Reflect.get(mod, key, reciver);
}

With use of Proxy, osModule would be a Proxy instance, and os module will be loaded only when we call one of its methods.

const osModule = impor('os'); // os module is not loaded
...
const platform = osModule.platform() // os module loads here

import {...} for ... is widely used when we only want to use part of the module. However, it may make Node have to access to the module to check its properties. Thus, getter will be executed and the module is loaded at that time.

Load modules with background job

Load on demand still is not enough. We can move forward a single step
to improve the user experience. Between the extension startup and the module requirement when user executes a command, we have enough time to load the module in advance.

It's an obvious idea to make a job in the background to load modules in a queue.

Timings

We built an extension called Azure IoT Device Workbench, which makes it easy to code, build, deploy and debug IoT project with multiple Azure services and popular IoT development boards.

Because of the big scope of Azure IoT Device Workbench touches, the extension is very heavy to activate. Also, it needs always to activate to listen USB event to take actions when IoT devices connect to the computer.

Figure 1 Activation timing of Azure IoT Device Workbench with lazy load and normal load

We have compared with lazy load and normal load for Azure IoT Device Workbench in different cases. From top to bottom in Figure 1, the charts are for launch without workspace open, non IoT project workspace open, and IoT project workspace open. The left charts are for cold boot, and the right for warm boot. Cold boot only happens when the extension is installed at the first time. After VS Code makes some caches, the extension always launches with warm boot. X-aixs is for time of millisecond, and Y-aixs is for loaded module number.

With normal load, the extension is activated at end of the chart. We find the extension is activated very advanced with lazy load with both cold boot and warm boot, especially when VS Code launches without workspace open.

For cold boot without workspace open, lazy load has ~30x speed to start up, and ~20x speed for warm boot. With non IoT project open, lazy load is ~10x faster then normal load for cold boot, and ~20x faster for warm boot. When VS Code opens an IoT project, Azure IoT Device Workbench needs require amount of modules to load the project, however, we still have ~2x speed with cold boot, and ~3x speed with warm boot.

Here're the complete timing charts for lazy load:

Figure 2 Complete timing of Azure IoT Device Workbench with lazy load

Same as Figure 1, the charts in Figure 2 are for both cold and warm boot with no workspace open, non IoT project workspace open, and IoT project workspace open.

Load timing stage of modules loaded by background job after activated shows in the charts very clearly. The user can hardly notice this small action, and the extension launches quite smoothly.

To make this performance improvement available to all VS Code extension developers, we have published a Node module called impor and have used it in Azure IoT Device Workbench. You can apply it in your project with very little code change.

Module Bundle

Almost all of the VS Code extensions have Node module dependencies. Because of the way Node module works, the depth of dependency level may be very deep. Other, structure of the module may be complex. And that is what Node module black hole talks about.

To clean up Node modules, we need an awesome tool, webpack.

Webpack is a static module bundler for modern JavaScript applications, such as VS Code extension. When webpack processes the application, it internally builds a dependency graph which maps every module the project needs and generates one or more bundles.

Tree shaking

Tree shaking is a term commonly used in the JavaScript context for dead-code elimination. It relies on the static structure of ES2015 module syntax, i.e. import and export. The name and concept have been popularized by the ES2015 module bundler rollup.

It is very easy to make a tree shaking with webpack. The only thing we need is to specific an entry file and its output name, webpack will handle the rest things.

With tree shaking, untouched files, including JavaScript code, markdown files, and etc, will be removed. Then webpack will merge all code into a single bundled file.

Code splitting

Merging all code into one file is not a good idea. To work with load on demand, we should split the code into different parts, and only load the part we need.

Now, to find a way to split code is another problem we need to solve. A feasible solution is to split every Node module into a single file. It is unacceptable to write every Node module path in webpack configuration file. Fortunately, we can use npm-ls to get all Node modules used in production mode. Then, in output section of webpack configuration, we use [name].js as output to compile every module.

Apply bundled modules

When we ask to load a module, happy-broccoli for example, Node will try to find happy-broccoli.js in node_modules folder. If the file doesn't exist, Node will try to find index.js under happy-broccoli folder in node_modules. If still fail, Node looks for main section in package.json.

To apply the bundled modules, we can put them into node_modules folder in tsc output directory.

If a module is incompatible with webpack bundle, it can be just copied to the output directory node_modules folder.

Here's an example of extension project structure:

|- src
|  |- extension.ts
|
|- out
|  |- node_modules
|  |  |- happy-broccoli.js
|  |  |- incompatible-with-bundle-module
|  |     |- package.json
|  |
|  |- extension.js
|
|- node_modules
|  |- happy-broccoli
|     |- package.json
|
|  |- incompatible-with-bundle-module
|     |- package.json
|
|- package.json
|- webpack.config.js
|- tsconfig.json

Without bundling Node modules, there are 4368 files in Azure IoT Device Workbench, and only 343 files are left after applying bundled modules.

Webpack config example

'use strict';

const cp = require('child_process');
const fs = require('fs-plus');
const path = require('path');

function getEntry() {
  const entry = {};
  const npmListRes = cp.execSync('npm list -only prod -json', {
    encoding: 'utf8'
  });
  const mod = JSON.parse(npmListRes);
  const unbundledModule = ['impor'];
  for (const mod of unbundledModule) {
    const p = 'node_modules/' + mod;
    fs.copySync(p, 'out/node_modules/' + mod);
  }
  const list = getDependeciesFromNpm(mod);
  const moduleList = list.filter((value, index, self) => {
    return self.indexOf(value) === index &&
        unbundledModule.indexOf(value) === -1 &&
        !/^@types\//.test(value);
  });

  for (const mod of moduleList) {
    entry[mod] = './node_modules/' + mod;
  }

  return entry;
}

function getDependeciesFromNpm(mod) {
  let list = [];
  const deps = mod.dependencies;
  if (!deps) {
    return list;
  }
  for (const m of Object.keys(deps)) {
    list.push(m);
    list = list.concat(getDependeciesFromNpm(deps[m]));
  }
  return list;
}

/**@type {import('webpack').Configuration}*/
const config = {
    target: 'node',
    entry: getEntry(),
    output: {
        path: path.resolve(__dirname, 'out/node_modules'),
        filename: '[name].js',
        libraryTarget: "commonjs2",
        devtoolModuleFilenameTemplate: "../[resource-path]",
    },
    resolve: {
        extensions: ['.js']
    }
}

module.exports = config;

Compare with webpack classic solution

Instead of bundling the entire extension, only bundling modules respectively can make a big benefit of packing. It is very possible that the extension throws dozens of errors after webpacked'. Splitting every module into a single file makes it easier to debug. Also, loading specific bundled module on demand will minimize the impact on performance.

Experiment Results

Module bundle is applied to Azure IoT Device Workbench with lazy load to compare with normal load.

Figure 3 Activation timing of Azure IoT Device Workbench with lazy load with bundled modules and normal load

Module bundle has decreased activation time sharply. For cold boot, lazy load even costs less time than normal load to load all modules completely in some cases.

	Normal Load	Webpack Classic Solution*	Lazy Load	Lazy Load with Bundled Modules**
No workspace, cold boot	19474 ms	1116 ms	599 ms	196 ms
No workspace, warm boot	2713 ms	504 ms	118 ms	38 ms
Non IoT workspace, cold boot	11188 ms	1050 ms	858 ms	218 ms
Non IoT workspace, warm boot	4825 ms	530 ms	272 ms	102 ms
IoT workspace, cold boot	15625 ms	1178 ms	7629 ms	2001 ms
IoT workspace, warm boot	5186 ms	588 ms	1513 ms	517 ms

*,** Some modules required by Azure IoT Device Workbench are incompatible with webpack, and are not bundled.
Table 1 Activation time of Azure IoT Device Workbench in different statuses

Activation time shows in Table 1 is between very beginning of the entry to the extension and the end of activate function:

// start of timing
import * as vscode from 'vscode';
...
export async function activate(context: vscode.ExtensionContext) {
    ...
    // end of timing
}
...

Usually, time before activated is longer then startup time shows in VS Code Running Extensions page. For example, when open IoT workspace with warm boot, the activation time is 517 ms in the table, but the startup time is ~200 ms in VS Code Running Extensions page.

Activation time of classic webpack solution only has relationship to boot mode, because all modules are always loaded in the same way. When applying lazy load on Azure IoT Device Workbench, it starts up further faster without workspace open than with IoT workspace open, no matter whether with or without bundled modules. When we open an IoT workspace, most modules are required, and the benefit taken from lazy load is not obvious, so lazy load with bundled modules has similar activation time with classic webpack solution.

Conclusion

In this article, a load bundled modules on demand method is proposed. A heavy extension called Azure IoT Device Workbench is tested for the method of multiple cases, and its startup speed has been increased to dozens of times. In some cases, this method also shows better performance than classic webpack solution.