npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@guscrawford.com/loft-interface

v0.0.4

Published

The command-line, REST, or any other integration interface controlling input to loft scaffolder

Downloads

10

Readme

Loft

Write less code, manage workspace clutter

Loft is a tool you can use anywhere to take a snapshot of code and re-scaffold to another folder.

You can copy work from anywhere, annotate the file with variables and re-generate your code ad-hoc for a new purpose.

Install | Create a Scaffold | Use a Scaffold

loft

noun

  1. a room or space directly under the roof of a house or other building, which maybe used for accomodations or storage.
  2. kick, hit, or throw (a ball or missile, or code) high up.
    • "he lofted the code out of his badly trashed home-directory"

When and why?

  • You have a lot of boiler-plate code outside of, or no longer manageable by another tooling framework.
  • You have local code that you don't want to publicize or gist, don't want to lose, but want out of your home directory.
  • You want to copy a working project as a more general seed.
  • You're doing something replicable, it's at a stage where it may be ready to be re-used separately, and you want to be able to extract and re-test it in isolation.

Why not...

  • Yeoman Yeoman is a mature, extensible scaffolder with a deep library of seed generators; Yeoman is my-man (punny), but I don't always need a code-generator nor am I "bound within it's guiderails" (have a team project where I can integrate a yeoman generator) in many cases.
    • Loft like Yeoman, is language agnostic.
    • Yeoman is opiniated by it's own concession, while Loft is not opinionated; it's focus is to further ignore workflow, frameworks, environment, etc. and just template files.
    • There is no presumption about the existing tooling in the framework or modification outside it's internal scaffolding activity.

Install

yarn global add @guscrawford.com/loft-interface

Create a Scaffold

Copy work anywhere to a folder in your home directory ($HOME|$USERPROFILE/.loft/scaffolds)

loft [<new> scaffold <my-snippet-name>] [path-to-snippet]

example:

loft new scaffold my-code ./src

  • default path-to-snippet is current directory if unspecified
  • <createable=scaffold> or "scaffold" argument above is required to rename a scaffold/snippet

Use a Scaffold

Copy work from your scaffolds into anywhere you're working.

loft <new> [workspace] my-snippet <target-directory>

example:

loft new my-code my-cloned-code

Annotate your Code with Variables & Replace Them

You can prep (or edit already stored code $HOME|$USERPROFILE/.loft/scaffolds) your code with commented annoations in any script language that has a way to comment, or write innocuous text that the scaffolding engine can pick up. (There are plans to add some kind of loft.config.json file so that one could externally scope variable replacements in a JSON file with rigid structure requirement, but for now you'd have to essentially add properties if you're not using JSON with comments).

example:

Presuming I already have a scaffold named any-command with this file in it commented as so:

//@loft:XXX
export class AnyXXXCommand extends LoftCommand{
    constructor (args) {
        super(args);
    }
    //@loft:xxx
    name = "xxx";
    async loadScaffolds() {
        await LoftToolkit.ensure(LOFT_PATH);
        return new Promise(
            function (res, rej){
                ...
            }
        );
    }
}

Running: loft new any-command help-command XXX Help file:xxx help

Will rename files matching the file: arguments to their supplied parameter, and replace file contents matching the @loft: variable prefix against the paramater pairs supplied in the XXX example.

example output:

//@loft:XXX
export class AnyHelpCommand extends LoftCommand{
    constructor (args) {
        super(args);
    }
    //@loft:xxx
    name = "help";
    async loadScaffolds() {
        await LoftToolkit.ensure(LOFT_PATH);
        return new Promise(
            function (res, rej){
                ...
            }
        );
    }
}

Complete Annotation List

@loft:<variable> - defines or 'scopes' a variable in the code for replacing; could be part of a variable, the whole thing, it currently can be any non-whitespace character to leave things open for further pattern matching, but for now is reccomended you use a variable name that will not break your code from running, un-annotated.

Scoping is good on a per-file basis. Matching filenames is currently at a whole-project scope and has no variable syntax beyond specifying a simple pattern to match on the command line with the file: prefixed argument.

@deloft:<variable> - removes or 'descopes' a variable in the code from any further replacing;

NPM