DEV Community: Folke Lemaitre

🚀⚡️ ts-node on steroids

Folke Lemaitre — Wed, 09 Dec 2020 16:26:02 +0000

I just released esbuild-runner. It makes it easy to run arbitrary code or tests without needing to build your whole project. It's a great way to improve your development workflow. Underneath it uses the fantastic and super fast javascript bundler esbuild

✨ Usage

The easiest way to use esbuild-runner is to install it globally and use the included esr binary.

$ esr hello-world.ts

Alternatively, you can require esbuild-runner within any nodejs process to include realtime transpilation:

$ node -r esbuild-runner/register hello-world.ts

In order to use esbuild-runner with Jest, you need to configure a Jest transform in your jest.config.js

module.exports = {
  transform: {
    "\\.ts$": "esbuild-runner/jest",
  },
}

⚙️ Configuration

esr provides two different ways to transpile your code:

bundling (default): this transpiles the script and all its dependencies in typically one invocation of esbuild. Dependencies defined in package.json or node_modules will never be transpiled. Running esr will always transpile the code. No caching is used.
transform (--cache): this method will invoke esbuild for every source file, but will cache the result. This means that the initial run will be slower, but after that, only changed source files will be transpiled.

$ bin/esr.js --help
Usage: esr [options] <source-file> [file-options]

  --cache       Transform on a file per file basis and cache code
  --clearCache  Clear transform cache
  --help|-h     Display this help message

📦 Installation

Simply install the esbuild-runner npm package using your favorite package manager.

globally ...

$ npm install -g esbuild-runner

... or locally in your project

$ npm add --dev esbuild-runner

👋 Contributing

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

⚖ License

Apache 2.0

🚀 Process Monitor for Node.js

Folke Lemaitre — Fri, 13 Mar 2020 12:02:52 +0000

We just released v2.2.0 of Ultra Runner with a new monitoring feature! Running ultra --monitor will show a process list similar to top, but only for Node.js processes.

✨ Features

sorted by CPU usage
tree view of parent/child processes
package or directory where the command was executed
cpu & memory usage
clean command line (use regular top to see the messy difference 😄)

Should work on Macos & Linux and probably on Windows (let me know if you have any issues)

🚀 Monorepo Workspace, a vs-code extension to manage monorepos with multi-root workspaces. Supports Lerna, Yarn, Pnpm and Rush

Folke Lemaitre — Thu, 05 Mar 2020 17:25:42 +0000

I just released Monorepo Workspace, a simple extension to work with monorepos in VS Code. Supported repositories: Lerna, Yarn, Pnpm, Rushjs and recursive package directories.

Features

All Monorepo Workspace functionality can be found in the command palette. Available commands:

Selecting a package:

Monorepo: Open Package (Current Window): open a package from your repository in the current window
Monorepo: Open Package (New Window): open a package from your repository in a new window
Monorepo: Open Package (Workspace Folder): add a package from your repository as a workspace folder

You can also create workspace folders for all your repository packages with Monorepo: Sync Workspace Folders:

🚀 Just released ultra-runner 2.0.0! Ultra fast script runner and build tool, with support for lerna, yarn and pnpm monorepos.

Folke Lemaitre — Wed, 04 Mar 2020 21:18:16 +0000

I've just released Ultra Runner 2.0.0 with lots of new features to run scripts and builds for monorepos.

✨ Highlights

zero-config: works out of the box with your existing monorepo
non-intrusive: no need to make any changes to your packages.json files
workspaces: detects packages in existing lerna, yarn and pnpm workspaces, or recusrively searches them
ultra fast builds: ultra keeps track of file changes in your repo and only actually build a package when needed
parallel builds: ultra builds your packages concurrently by default
workspace dependencies: workspace dependencies are automatically resolved and used for parallel builds
execute anything: one command to run package scripts, node_modules binaries or system binaries, recursively in your repository.
faster script execution: ultra hijacks any npm, pnpm, yarn and npx calls for faster execution.
concurrency within scripts: you can add optional configuration to package.json to run parts of a script in parallel. No need to change the actual scripts
filtering: filter on package names or subdirectories

🏃⛰ Smarter, prettier and faster package scripts with Ultra-Runner

Folke Lemaitre — Wed, 22 Jan 2020 15:58:09 +0000

Smart and beautiful script runner that hijacks any npm run, yarn and npx calls for ultra fast execution.

❓ Why

Use one command to run package scripts, locally installed binaries or system binaries

	`npm run`	`npx`	`yarn`	`yarn exec`	`ultra`
`package.json` scripts	✅	❌	✅	❌	✅
`./node_modules/.bin/`	❌	✅	✅	✅	✅
system binaries	❌	✅	❌	✅	✅

🤓 Smart

Ultra parses your package.json and hijacks any npm run, yarn and npx calls.
Shell operators like &&, ; and || are also interpreted.

For example:

{
  "scripts": {
    "lint": "yarn lint:ts && yarn lint:eslint && yarn lint:docs",
    "lint:eslint": "npx eslint bin/*.js src/*.ts __tests__/*.ts --cache",
    "lint:docs": "npx markdownlint README.md",
    "lint:ts": "npx tsc -p tsconfig.build.json --noEmit",
    "lint:fix": "yarn lint:eslint --fix"
  }
}

Running ultra lint

Running ultra lint:fix will spawn exactly one child process, directly with the correct command, instead of spawning yarn intermediately

Ultra will additionally execute any configured pre and post scripts, just like npm run and yarn run.

⚡ Ultra Fast

Ultra parses your package.json scripts and will only execute the commands that are really needed. Any script interdependencies are resolved during the parsing stage.
This ensures there's pretty much no overhead in execution by Ultra itself, since it's only running once.
yarn run or npm run on the other hand, will spawn new yarn or npm child processes as needed by the package scripts.

	`npm run`	`npx`	`yarn`	`yarn exec`	`ultra`
execution overhead (1)	250ms	60ms	220ms	200ms	80ms

^{1. each program was run 10x with the command true or {scripts:{"true":"true}} to calculate the execution overhead}

Suppose you would want to run a script that calls 5 other scripts by using && and/or post/pre.

Using yarn, you would have a total overhead of 2.5s (10x 250ms)
Using ultra, you hit the overhead only once, so the total overhead would still be 80ms

To make execution ultra fast, you can configure which scripts should be ran concurrently.

❕ there's no need to switch your scripts over to ultra. Even with the optional configuration you can still use yarn or npm to run your scripts if you want to.

Example builds:

	`yarn`	`ultra` not concurrent	`ultra` concurrent
build Ultra-Runner	8.9s	7.2s	5.1s
build Devmoji	16s	13s	8s

👸 Beautiful

There are three output formats that each can be combined with --silent to hide command output.

--fancy is the default. It shows output in a hieracrhical way and uses spinners to see exactly what's happening.
Make sure to check out the animation at the top of this page as well. Every executed step shows the execution time.

--fancy combined with --silent is useful if you're only interested to see the overview:

--no-fancy doesn't use spinners and prefixes command output with the command name. This is useful for logging purposes.

Combining --no-fancy with --silent shows a flat overview:

--raw will show the exact ouput as you would expect when running the commands stand alone. If the command you're executing is interactive (reads from stdin), then this is the mode you should use.

📦 Installation

Install with npm or yarn

globally

npm install -g ultra-runner
yarn global install ultra-runner

locally inside your project. use with npx ultra

npm install --dev ultra-runner
yarn add --dev ultra-runner

See optional configuration for information on how to setup concurrent script execution.

🚀 Usage

$ ultra --help
Usage: ultra [options]

Options:
  -c|--concurrent  Run the given commands concurrently
  -p|--parallel    alias for --concurrent
  --fancy          enable fancy output, spinners and seperate command output. Default when a TTY (default: true)
  --no-fancy       disables fancy output, spinners and seperate command output. Default when not a TTY. Useful for logging
  --raw            Output only raw command output
  -s|--silent      skip script output. ultra console logs will still be shown
  --color          colorize output (default: true)
  --no-color       don't colorize output
  -d|--dry-run     output what would be executed
  -v|--version     output the version number
  -h, --help       output usage information

use --concurrent to quickly run some commands in parallel. Any of the commands below are valid:
- ultra --concurrent lint \; test \; build
- ultra --concurrent "lint ; test ; build"
- ultra --concurrent "lint && test && build"
use --dry-run to see what would be executed. The output is similar to --fancy --silent

⚙️ Optional Configuration

To allow parallel execution of your scripts, you can specify scripts that should run concurrently,
in your package.json.

{
  "scripts": {
    "lint:eslint": "npx eslint bin/*.js src/*.ts __tests__/*.ts --cache",
    "lint:docs": "npx markdownlint *.md",
    "lint:ts": "npx tsc -p tsconfig.build.json --noEmit",
    "lint": "yarn lint:eslint && yarn lint:docs && yarn lint:ts",
    "prebuild": "yarn lint && yarn jest",
    "build": "..."
  },
  "ultra": {
    "concurrent": ["lint"]
  }
}

yarn build will run the lint and jest commands sequentially
ultra build will run all lint commands concurrently and then execute jest. (note that we can also add prebuild to concurrent, since tests don't depend on linting. this way all commnands would run concurrently)

Notice how the sum of execution times of the seperate lint commands is lower than the total time:

🤖 🚀 ✨ Emojify your conventional commits with Devmoji

Folke Lemaitre — Thu, 16 Jan 2020 13:58:06 +0000

Using Conventional Commits ⭐ as a standard for your commit messages, makes Semantic Versioning 🔖 as easy as can be, with tools like Conventional Changelog 📄,Standard Version 🔖 and Semantic Release 📦🚀

Devmoji is a command line tool that adds color 🌈 to conventional
commits, using emojis inspired by
Gitmoji 😜

Some of the things Devmoji can do:

emojify: convert input between diferent emoji formats unicode, shortcode and devmoji. devmoji are easy to remember aliases like: :test:, :refactor:, :docs:, :security instead of hard to remember emoji codes
git commit: install a prepare-commit-msg commit hook to ✨ automagically emojify your commit message
git log: emojify and colorify the output of git log even for projects not using emojis

What does it look like?

see the commit messages of the Devmoji github repository
generated Devmoji CHANGELOG.md

📦 Installation

Install with npm or yarn

globally



npm install -g devmoji
yarn global install devmoji

locally inside your project. use with npx devmoji



npm install --dev devmoji
yarn add --dev devmoji

See --edit for information on how to setup a git commit
hook.

💥 Usage

`devmoji --help`



$ devmoji --help
Usage: devmoji [options]

Options:
  -c|--config <file>    location of the devmoji.config.js file
  -l|--list             list all known devmojis
  -t|--text <text>      text to format. reads from stdin when omitted
  -f|--format <format>  format should be one of: unicode, shortcode, devmoji (default: "unicode")
  --commit              automatically add a devmoji to the conventional commit header (default: true)
  --no-commit           do not process conventional commit headers
  -e|--edit             read last commit message from .git/COMMIT_EDITMSG in the git root
  --log                 format conventional commits in text similar to git log
  --color               use colors for formatting. Colors are enabled by default, unless output is piped to another command (default: true)
  --no-color            don't use colors
  --version             output the version number
  -h, --help            output usage information

`devmoji` emojify

Emojify text using --text or piping it to stdin. Input can be a combination
using any valid format. Output formats:

Format	Description
`shortcode`	outputs Github Markdown short codes like `:sparkles:` `:rocket:`
`unicode`	outputs the emoji unicode symbols like ✨ 🚀
`devmoji`	outputs the devmoji shortcodes like `:feat:` `:chore-release:`
`strip`	removes all emoji from the input

The default format is unicode, since this can be used pretty much everywhere
and has the shortest text length (relevant for commit messages)



$ echo "This is a :test: of the first :release: :boom: ✨" | devmoji --format shortcode
This is a :rotating_light: of the first :rocket: :boom: :sparkles:

$ echo "This is a :test: of the first :release: :boom: :sparkles:" | devmoji --format unicode
This is a 🚨 of the first 🚀 💥 ✨

$ echo "🚀 :boom: :sparkles:" | devmoji --format devmoji
:chore-release: :breaking: :feat:

$ echo "test 🚀 :boom: :sparkles: :security:" | devmoji --format strip
test

`devmoji --commit`

Automagically ✨ emojifies a conventional commit message of the format
type(scope): something useful, using the following pseudo code:



if (exists(":type-scope:")) return emoji(":type-scope:")

if (exists(":type:") && exists(":scope:"))
  return emoji(":type:") + emoji(":scope:")

if (exists(":type:")) return emoji(":type:")

example ouput:



$ echo "feat: added a new feature :smile:" | devmoji --commit
feat: ✨ added a new feature 😄

$ echo "chore(release): 1.1.1" | devmoji --commit
chore(release): 🚀 1.1.1

$ echo "fix(security): upgraded lodash" | devmoji --commit
fix(security): 🐛 🔒 upgraded lodash

`devmoji --edit`

Formats and saves your current commit message .git/COMMIT_EDITMSG. This is
only really useful as a prepare-commit-msg hook.

Configuration using Husky



// package.json
{
  "husky": {
    "hooks": {
      "prepare-commit-msg": "devmoji -e"
    }
  }
}

Configuration using Yorkie



// package.json
{
  "gitHooks": {
    "prepare-commit-msg": "devmoji -e"
  }
}

If you installed Devmoji locally in your project as a dev dependency, then
use something like npx --no-install devmoji -e instead of the commands
above.

`devmoji --log`

Works similar to --commit, but formats type(scope): something useful
anywhere in the input instead of the beginning of the first line.

This is useful to format the output of git log. Any git log option works,
but my favorite alias is:



$ git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --decorate --date=short

I'll use my alias git l, instead of the above, for clarity. The
devmoji --format strip is only for demonstration purposes, since all devmoji
commits already have emoji

using devmoji --log >

`devmoji --list`

To get a list of all available Devmiji, run with --list. (see also
Default Devmoji)

⚙️ Configuration

devmoji uses the config file as specified with the --config option, or looks
for devmoji.config.js in the following paths:

current directory
parent directory that contains a package.json file
parent directory that is a git repository
home directory

Example Config File



export const defaults = {

  // extra types used in commit messages

  types: ["lint"],

  // custom devmoji

  devmoji: [

    // use :boom: instead of :sparkles: for the type 'feat'

    { code: "feat", emoji: "boom" },

    // add a custom devmoji

    {

      code: "fail",

      emoji: "poop",

      description: "something bad happened",

    },

    // add a new devmoji based on an existing gitmoji. description will be taken from the gitmoji

    {

      code: "css",

      gitmoji: "art",

    },

    // the emoji from the gitmoji can be overriden as well

    {

      code: "config",

      gitmoji: "wrench",

      emoji: "gear",

    },

  ],

}

Default Devmoji Reference

Emoji	Devmoji Code	Description
✨	`:feat:`	feat: a new feature
🐛	`:fix:`	fix: a bug fix
📚	`:docs:`	docs: documentation only changes
🎨	`:style:`	style: changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
♻️	`:refactor:`	refactor: a code change that neither fixes a bug nor adds a feature
⚡	`:perf:`	perf: a code change that improves performance
🚨	`:test:`	test: adding missing or correcting existing tests
🔧	`:chore:`	chore: changes to the build process or auxiliary tools and libraries such as documentation generation
🚀	`:chore-release:`	chore(release): code deployment or publishing to external repositories
🔗	`:chore-deps:`	chore(deps): add or delete dependencies
📦	`:build:`	build: changes related to build processes
👷	`:ci:`	ci: updates to the continuous integration system
🚀	`:release:`	code deployment or publishing to external repositories
🔒	`:security:`	Fixing security issues.
🌐	`:i18n:`	Internationalization and localization.
💥	`:breaking:`	Introducing breaking changes.
⚙️	`:config:`	Changing configuration files.
➕	`:add:`	add something
➖	`:remove:`	remove something

DEV Community: Folke Lemaitre

🚀⚡️ ts-node on steroids

✨ Usage

⚙️ Configuration

📦 Installation

👋 Contributing

⚖ License

🚀 Process Monitor for Node.js

✨ Features

🚀 Monorepo Workspace, a vs-code extension to manage monorepos with multi-root workspaces. Supports Lerna, Yarn, Pnpm and Rush

Features

🚀 Just released ultra-runner 2.0.0! Ultra fast script runner and build tool, with support for lerna, yarn and pnpm monorepos.

✨ Highlights

🏃⛰ Smarter, prettier and faster package scripts with Ultra-Runner

❓ Why

🤓 Smart

⚡ Ultra Fast

👸 Beautiful

📦 Installation

🚀 Usage

⚙️ Optional Configuration

🤖 🚀 ✨ Emojify your conventional commits with Devmoji

📦 Installation

💥 Usage

devmoji --help

devmoji emojify

devmoji --commit

devmoji --edit

devmoji --log

devmoji --list

⚙️ Configuration

Example Config File

Default Devmoji Reference

`devmoji --help`

`devmoji` emojify

`devmoji --commit`

`devmoji --edit`

`devmoji --log`

`devmoji --list`