This code contains some helper functions for testing xstate v5+ Actor and Machine behavior using Promises and "traditional" assertions (vs state-machine-based testing).
Maybe I'll put some examples here.
Instead of this, see xstate-audition which I built upon this idea (with less OOP).
| // @ts-check | |
| 'use strict'; | |
| /** | |
| * @returns {import('wallabyjs').IWallabyConfig} | |
| */ | |
| module.exports = (wallaby) => { | |
| return { | |
| env: { |
| import { ActorRef, ActorRefFrom, assign, setup } from 'xstate'; | |
| type EmittedEvents = {type: 'BAR'}; | |
| const machineB = setup({ | |
| types: { | |
| input: {} as { | |
| a: ActorRef<any, any, EmittedEvents> | |
| }, | |
| }, |
| #!/usr/bin/env node | |
| /* eslint-disable n/shebang */ | |
| // @ts-check | |
| /** | |
| * Prints a `memfs` volume JSON from the filesystem given glob patterns and/or | |
| * directories | |
| * | |
| * Directories are handled recursively | |
| * |
As of TS v5.0.0, you can use @overload in JSDoc which means this document is obsolete.
Yes, you can. No, it's not pretty.
I tested some different packages with different TS configurations, and you won't believe what happened next.
The top row of this table lists providers--modules which export type definitions. The left-hand column lists consumers--modules which import type definitions from the providers.
Each consumer header cell will contain three (3) values:
This guide aims to get you setup with Visual Studio Code (as opposed to Visual Studio or MonoDevelop) for developing Stardew Valley mods using SMAPI.
Why would you want to use VS Code to mod Stardew? A couple reasons:
There are many threads about this, but in a nutshell, the problem is that only a relatively small number of subscriptions can be shown in the blueprint library. I found myself having subscribed to some 700-odd blueprints before I realized this.
The workaround is to just copy the workshop blueprints into the game's blueprints folder. Each workshop blueprint is in its own folder, and only the files in those folders should be copied. But with 700 blueprints, doing this manually is unappealing.
I did this with a Bash script instead. It can be done with a one-liner, but I've split it up a bit to hopefully make it more approachable. Maybe there's an easier way?
Before starting, you'll need to determine:
C:\Program Files (x86)\Steam\steamapps\workshop\content\383120. You may have to do some poking around, since I'm not sure if the number is constant.Appium 2 supports configuration files. A configuration file is intended to have (nearly) 1:1 parity with command-line arguments. An end user can supply Appium 2 with a configuration file, CLI args, or both (the args have precedence over the config file).
This document will be a technical overview of how the configuration system works. It is intended for Appium contributors, but will also explain the system's fundamental features.
A config file is a JSON, JavaScript, or YAML file which can be validated against a schema. By default, this file will be named .appiumrc.{json,js,yaml,yml} and should be in the root of the project which depends upon appium. Other filenames and locations are supported via the --config <file> flag. For obvious reasons, the config argument is disallowed within config files.
| proc tile_entity {} { | |
| set tile_entity_type [uint8] | |
| int32 "ID" | |
| int16 "x" | |
| int16 "y" | |
| if {$tile_entity_type == 0} { | |
| int16 "Target Dummy" | |
| } elseif {$tile_entity_type == 1} { | |
| itemstack "" | |
| } elseif {$tile_entity_type == 2} { |