reaganmcf / lightmon

A lightweight, cross-platform, language-agnostic "run code on file change" tool, inspired by Nodemon

lightmon

A lightweight, cross-platform, language-agnostic "run code on file change" tool, inspired by Nodemon

Why lightmon over nodemon?

There are many reasons to use lightmon over nodemon: it's faster, lighter, and can be used for all types of projects. Not only this, but lightmon is a drag and drop replacement for projects that use nodemon because lightman can parse existing nodemon.json config files.

• Note: Parse nodemon.json config is still WIP

Usage

lightmon

By default, lightmon will automatically determine what kind of files it should watch based upon your project structure. For example, if a node_modules folder is present in the directory, lightmon will run in the node configuration, parsing your package.json to infer the correct command to run.

Supported languages

Watch patterns are the file patterns that lightmon will watch for file changes, and Exec commands are the list of commands that are executed when those events happen.

Rust

lightmon rust [cargo_subcommand]? [cargo_subcommand_args]?

Watch Patterns

[Cargo.toml, .rs]

Exec Commands

By default, the rust configuration will set the Exec command to cargo run if it's a binary project, and cargo test if it's a library.

However, you can override this behavior by specifying any valid cargo subcommand (and any arguments). For example, if you wanted to run cargo build --bin my_bin --all-targets, you can run the following:

lightmon rust build --bin my_bin --all-targets

Refer to lightmon help rust for more information.

Node.js

Note: This configuration also works for React, React-Native, TypeScript, etc. i.e.: anything with a package.json!

lightmon node

Watch Patterns

[.jsx, .js, .css, .html]

Exec Commands

If there is a package.json in the root directory, lightmon attempts to resolve the exec command in the following order:

• The value at scripts.start
• node main where main is the value of the main key in package.json (the entry point of the project).

NOTE: The Exec command will fallback to node index.js if all of the above fail.

For example, the following package.json will result in the Exec command resolving to react-scripts start:

{
  "name": "calculator",
  "main": "index.js",
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build"
  }
}

C/C++

It's very tricky to infer what the patterns and exec commands could be, so we recommend using shell mode with a custom script (see below).

Shell (for unsupported languages or complicated builds)

lightmon shell -s <path> -w <patterns> Here users can specify the path to the shell script and which file types to watch for seperated by commas.

For example, let's say you have a python project with a file named start.py at the root of the project. Whenever you edit any .py files in the project, you want to re-run python start.py. To accomplish this, you could create a simple script called run.sh with the following contents:

python start.py

Now, you just run the following:

lightmon shell -s run.sh -w .py,.ipynb

Installation

There are many ways to install lightmon. We recommend using our install script as it is the fastest method.

$ curl -sSL https://raw.githubusercontent.com/reaganmcf/lightmon/master/install.sh | sh

But, we also support other popular package managers if you would rather use them instead:

cargo

$ cargo install lightmon

Arch AUR

$ yay -S lightmon

License

lightmon uses the GNU GPL v3.0 License

Attributions

Icons made by Freepik from www.flaticon.com

lightmon's Issues

Add CHANGELOG

Add to repo to track progress between versions

Add golang support

Add support for Golang

Add poll watcher duration as a cli argument

Currently, the default time interval for the poll watcher is 100ms as shown on line 22 in watcher.rs

I don't know what the default should be, but 100ms seems fine for now. However, this value should definitely be a command-line argument. I am thinking -d for short form and --duration for the long form.

Restart program without killing lightmon

similar to nodemon's restart feature, we should implement a user enabled restart of their program even if no changes are made.

Kill exec child when file changes cause restart

Allow arguments to be passed in to override params in the install script

For example, being able to set the install location (right now it is usr/local/bin) would be a really nice addition to have.

For shell mode: Ensure that path to shell script actually exists.

Make sure no bad args passed

Allow cargo subcommands (test, doc, fmt, clippy) as cli options for rust configuration

Currently, lightmon rust only supports cargo build since that is how cli::build_rust_config() works. But even while working on this project, I want to be able to do cargo test or cargo doc without the shell script method. Being able to pass in the common cargo subcommands would be nice:

$ lightmon rust doc
$ lightmon rust test

Apple M1 Support

Add targets in CI for Apple M1

Improve documentation for docs-rs

I have already sorta started this as seen on

lightmon/src/cli.rs

Line 74 in 1fe8f33

/// Build the `nodejs` configuration.

, but building it fully out would be nice for v0.2.0

`cli::build_node_config()` should be smarter

Running lightmon in node configuration should run node on the entry point of the project. if start or run is not present as a key in script inside package.json.

The standard filename for the entry point is index.js, but the main property in a package.json will give us the name of the entry file.

Example package.json

{
  "name": "node_basic",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

Since there is no start or run entry in the scripts object, we should default to running node on the value of the main key.

However, we could also have this package.json:

{
  "name": "example",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "start": "node node_modules/react-native/local-cli/cli.js start",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

In this case, exec should be npm start.

Make output messages more user friendly and informative

Make stdout easier to read and friendly. Some ideas:

• When exec command succeeds, some sort of Successfully ran. Monitoring for file changes... message to stdout in some color
• When lightmon starts, some sort green(?) message showing it started

Parse nodemon.json config files

If a nodemon.json is present in the current directory, parse nodemon's config file (nodemon.json) into lightmon's equivalent arguments. This would enable lightmon to be a 0 friction drag-and-drop replacement to nodemon for users that have nodemon configurations.

We would need to ensure that we have some sort of equivalent for every command line option they have, which might not be what we want to do. Should definitely look more into this to see if it's something we actually want to do, but the benefits seem to usability seem tremendous!

Include STDERR to output

I was running some script (for a C project) with the following configuration

lightmon shell --script-path run_test.sh --watch-patterns .c,.h

run_test.sh:

#!/bin/sh
make clean;
make;
cd benchmark;
make clean;
make;
./test

It was working pretty well, but if it ever errored out it would not tell me (and just hang)

• In my case, if I saved the file and the make failed due to a missing semi-colon or typo

I propose we have some sort of message like the following in red text whenever the exec thread fails.

ERR: Failed to run exec command

However, we should make sure not to kill the lightmon process!. Nodemon kills the process whenever this happens. I feel like 99% of the time when the build fails, it's because the changes in the code have a temporary bug that will be fixed on the next save anyway.

Implement automatic language resolution

Just running lightmon should try to automatically determine what the watch patterns and exec commands should be used. This is fairly trivial for configurations such as rust and node, but will almost be impossible for languages like c and c++

Load arguments from config file

Load configuration/arguments from a lightmon.toml file that would be located in the root directory of a project. This is a feature in Nodemon that is essential for complicated configurations.

Add more installation methods

Important for our first major release to have as many ways to install on every platform

• brew
• aur
• curl and pipe into shell

Build out test suite

Integration and unit tests. Integration tests are pretty tricky for this kind of project but we should definitely figure out a way to implement them.