A real deno app: Pagic

xcatliu — Thu, 21 May 2020 12:09:10 +0000

The easiest way to generate static html page from markdown, built with Deno! 🦕

GitHub

Features

Markdown + Layout => HTML
React component as a page
Copy static files
Sub pages and layouts
Front matter

Getting started

Installation

# Install deno https://deno.land/#installation
curl -fsSL https://deno.land/x/install/install.sh | sh
# Install pagic
deno install --unstable --allow-read --allow-write --allow-net https://raw.githubusercontent.com/xcatliu/pagic/master/pagic.ts

Markdown + Layout => HTML

Let's say we have a project like this:

docs/
├── public/
└── src/
    ├── _layout.tsx
    └── index.md

The src/_layout.tsx is a simple react component:

// @deno-types="https://deno.land/x/types/react/v16.13.1/react.d.ts"
import React from 'https://dev.jspm.io/react@16.13.1';
import { PagicLayout } from 'https://raw.githubusercontent.com/xcatliu/pagic/master/pagic.ts';

const Layout: PagicLayout = ({ title, content }) => (
  <html>
    <head>
      <title>{title}</title>
      <meta charSet="utf-8" />
    </head>
    <body>{content}</body>
  </html>
);

export default Layout;

The src/index.md is a simple markdown file:

# Pagic

The easiest way to generate static html page from markdown, built with Deno! 🦕

Then run:

pagic build

We'll get an index.html file in public directory:

docs/
├── public/
|   └── index.html
└── src/
    ├── _layout.tsx
    └── index.md

The content should be:

<html>
  <head>
    <title>Pagic</title>
    <meta charset="utf-8" />
  </head>
  <body>
    <article>
      <h1 id="pagic">Pagic</h1>
      <p>The easiest way to generate static html page from markdown, built with Deno! 🦕</p>
    </article>
  </body>
</html>

Other features please see GitHub

How eslint-config-alloy become the third welcomed ESLint config in the world

xcatliu — Thu, 26 Dec 2019 05:05:03 +0000

eslint-config-alloy is an ESLint config which created by Tencent AlloyTeam. Since the first version was released in August 2017, it has unknowingly gained 1.3k stars, and becoming the third-ranked ESLint config in the world (first is airbnb and second is standard).

For more than two years, we have rarely promoted it, mainly relying on word of mouth and growing naturally. So what’s so special about eslint-config-alloy?

Philosophy

Let Prettier handle style-related rules
Inherit ESLint's philosophy and help everyone build their own rules
High degree of automation: advanced rules management, test as document as website
Keep up with the times, follow up the latest rules as soon as possible

Let Prettier handle style-related rules

Prettier is a code formatting tool that offers fewer options but is more professional than the style-related rules in ESLint.

Now that Prettier has become a necessary tool in front-end projects, eslint-config-alloy does not need to maintain the style-related rules in ESLint anymore, so we completely removed all Prettier related rules in the v3 version, and use ESLint to check logical errors which it's good at.

As for whether two spaces or four spaces are used for indentation and whether there is a semicolon at the end, you can configure it in the project's .prettierrc.js. Of course, we also provide a recommended Prettier configuration for your reference.

Inherit ESLint's philosophy and help everyone build their own rules

Don't you remember how ESLint defeated JSHint and became the most popular JS code inspection tool? It is because of the plugin and configuration that ESLint advocates, which meets the individual needs of different technology stacks of different teams.

Therefore, eslint-config-alloy also inherits the philosophy of ESLint. It will not emphasize the need to use our config. Instead, we help you to make your own config by reference our completed documents, examples, tests, websites, etc.

High degree of automation: advanced rules management, test as document as website

Relentless push automation

eslint-config-alloy uses a high degree of automation to hand over all processes that can be managed automatically, including:

Through greenkeeper and travis-ci, automatically check whether ESLint and related plugins have new versions, and if there are new rules in the new version which we need to add
Automatically check if our rules include Prettier rules
Automatically check if our rules include deprecated rules

In addition, through automated scripts, we can even divide and conquer thousands of ESLint configuration files, and each rule is managed in a separate directory:

Integrate single configurations into a final configuration through a script
The description and reason in single configurations are built into a website by script for everyone to view
The bad.js andgood.js in a single configuration are output to website by script, and you can even see the error message (which are run in a real ESLint script) in the bad.js of website

The benefits of this are very obvious, test as document as website. We can maintain the rules and tests in one place. Other tasks are handed over to the automated script, which greatly reduces the maintenance cost. In short, when we have a new rule to add, we only need to write three files test/index/another-rule/.eslintrc.js, test/index/another-rule/bad.js, test/index/another-rule/good.js.

Keep up with the times, follow up the latest rules as soon as possible

ESLint is updated very quickly, there is a new version almost every week, sometimes there are new rules, sometimes existing rules are deprecated, and related plug-ins (React/Vue/TypeScript) will be updated from time to time. Without automation tools, it is difficult follow up.

And eslint-config-alloy can receive the greenkeeper issue as soon as possible through the above automation tools, tell us which plugin has been updated, and the travis-ci build log will tell us which rules need to be added:

In this way, we can follow the latest rules in time when the front-end community is changing rapidly, and always keep the vitality and advanced of eslint-config-alloy.

Q & A

Why anthor ESLint config

In fact, our team initially used airbnb rules, but because it was too strict, some rules still needed to be personalized, which led to more and more changes in the future, and finally decided to maintain a new set. After more than two years of polishing, eslint-config-alloy is now very mature and progressive, and has been welcomed by many teams inside and outside the company.

Why not standard

The standard specification believes that everyone should not waste time in personalized specifications, but the entire community should unify a specification. This statement makes some sense, but it runs counter to ESLint's design philosophy. Don't you remember how ESLint defeated JSHint and became the most popular JS code inspection tool? It is because of the plugin and configuration that ESLint advocates, which meets the individual needs of different technology stacks of different teams.

Why not airbnb

eslint-config-alloy has officially maintained vue, typescript and react+typescript rules. In contrast, airbnb's vue and typescript are maintained by third parties.
Progressive to ensure that we can keep up with the times, as mentioned earlier
Convenient personalization, including explanations and website examples

Looks good, but I still choose airbnb

It ’s okay, eslint-config-alloy believes that different teams and projects can have different configurations from the design concept. Although you choose to use airbnb, you can still come to us website when you have personalized configuration needs.

DEV Community: xcatliu