Skip to content

Tooling: Snippets CLI #214

@43081j

Description

@43081j

shadcdn has commands like the following:

npx shadcn@latest add button

This basically adds a copy of shadcn's button (including all package.json changes, related files, css, etc) to your own repo.

This means you don't actually depend on a button package, but have your own "fork" you can later modify/redesign/etc.

The approach basically means very tailored things can start from a common base, but don't need to be tied to an npm dependency (tree) for it.

Applying this to snippets

A thought here is: can we apply this to utilities too?

Imagine:

npx tbd@latest add camelcase

For extremely small utilities ("micro utilities"), this could be a smarter move than depending on an npm package. Primarily:

  • You can later customise them to be more performant and concise for your specific use
  • They don't need to be as generic as their npm counterparts (since it is assumed you'll build on top, i.e. it is a base)
  • Performance improvements are easier by owning the code (e.g. two helpers reusing computed values, caches, etc)

Of course, the downsides:

  • Updates are difficult or non-existent (i.e. if we ship an update to the base, people may not be able to adopt it if they already changed the code enough)
  • In libraries, code duplication may go up (assuming libraries shouldn't be bundling themselves usually)

But even with these downsides, it probably makes sense to make the option available. Users can decide if they want to inline utils, or have dependencies.

Basic features

Commands:

  • Add
    • Adds a utility if it doesn't exist already to the utilities file
  • Init
    • Basically creates the initial utilities file

Manually curate utilities (initially)

We don't need to bother trying to automate this stuff yet. We can just create a directory of utilities and those are made available via the CLI.

Utilities need docs

Each utility should have documentation to explain:

  • Options
  • General usage
  • Common recipes (i.e. changes you might make to it once you've added it)

Advanced features - compile-time utilities

We could go further and have this DX:

import {isEven} from 'tbd/macros'; // doesn't actually exist, its just type defs

But we'd provide a CLI command and build plugins which replace usages of this with the inline code itself:

Build output:

if (2 % 2 === 0) {
}

We could offer this as build plugins for rolldown/rollup/esbuild/etc, too.

We should look into prior art for this, anyone who already implemented macros as js build plugins.

Open questions

  • Should we have a utilities file? The current proposal is exactly that, but maybe we can be smarter here. We could possibly ask the user if they want to add it to a specific file, for example.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions