DEV Community

Jim Burbridge
Jim Burbridge

Posted on

Into the Fray: A Dive into Deno

Tl;Dr: I just wanted to build a simple CLI in Deno, and now I've made at least 5 repositories related to Deno in the search to flush out the ecosystem. I'm not done yet.

Backstory

I've been following Deno since stumbling across Ryan Dahl's talk about things he wishes he'd have done different with Node JS(embedded below).

When 1.0 came out I was itching to try and do something with the runtime. Recently, I got a chance to try something.

Previously where I worked we had a Design Token library. I wasn't entirely sure how it worked, but in thinking about it I thought it should be easy to make something that would generate tokens for my own projects.

Well, I made it.

GitHub logo jhechtf / design-tokens

Design token generator written in Deno + TS

Raven (Design Token Generator)

Trying to create design tokens that can be used in CSS, SCSS, and Javascript/Typescript?

Yeah, me too.

Notes

In the end I hope that there will be two ways that users can use this library:

  1. In code, by importing the relevant items / functions and building it themselves or
  2. By using a CLI tool with a config file (aiming for it to be TS, but considering JSON) to generate it the necessary files in one shot.

Usage

Currently the code can be used with the following examples.

import { MediaQuery, Stylesheet, Token } from './mod.ts';
// Creates a new stylesheet
const stylesheet = new Stylesheet();
// create the tokens.
const primaryToken = new Token('primary-color', '#fecc99');
const spacingToken = new Token('gap', '4px', 'size');
const blueToken = new Token('blue-100'
Enter fullscreen mode Exit fullscreen mode

As Deno (in particular deno.land/x/) works with GitHub when a tag is pushed to the repository I had wanted to do something like NodeJS' "Standard Version." I asked on the Github page if there was a plan to port Standard Version over to Deno, and after not receiving a response I started on Version Bump(aren't I the greatest at names?).

This portion took quite a bit of time, and went through at least 2 system overhauls that I can remember. My goal was to make Version Bump much more pluggable than Standard Version was, and in doing that I had to be very careful with how I worked with things. I could honestly write a whole post about Version Bump, but I had wanted to hit a 1.0 release but wanted to ensure I had hit a code coverage target before going forward.

Well, turns out there's built in code coverage in Deno's testing, and even a way to get it into a format that isn't totally weird. Downside though, is that there wasn't a way I found to get this information into a report table like I was accustomed to (thanks Jest).

Can you guess what I did next?

That's right, built my own!. Code Coverage Takes an LCOV file generated through test data and the deno coverage command and outputs a nice little table for you.

Except the table breaks the viewport when you have a larger file that has many missing blocks of text.

I had to build Terminal Size, using a combination of a very nice Rust package and Deno's Foreign Function Interface in order to get this to work. However, this meant that I had to use a different table library because the one I was using wouldn't be work with the terminal size out of the box. Yup, another package.

ASCII Table Uses the terminal size library to get the terminal size if requested. Unfortunately this requires a lot of permission from Deno's sandbox, and the use of the --unstable flag so I doubt people will use it until it no longer requires that flag.

Impressions

What have you learned?

A couple of things:

I really enjoy Deno.

Direct TS? No fiddling with TS-Node or having to declare TS as a package? I love it.

Since it is newer, it's ecosystem is not as flushed out.

This ends up showing up in weird places; you know, like trying to get your code coverage into a quick and precise format. I'm going to see about contributing back to the deno project's coverage command, but I feel like I should know more about Rust before doing that. I don't want for the Code Coverage tool to be a necessary third-party tool in the Deno ecosystem going forward.

Sometimes the permissions thing feels a little like it gets in the way.

Especially for CLI libraries such Raven, Version Bump, or Code Coverage. On the one hand being able to run and install a library only in the current directory could be great, but on the other it feels more like a hurdle than anything else. One thing I wish I could've done was determine if the current script was being run with the --unstable flag to dynamically load my terminal library, allowing people who aren't using the full-width feature to scope down their permissions.

Please feel free to try out any of the tools I've made, and any ideas for improvements please go ahead and create an issue on the given Github. Any PRs are welcomed!

Top comments (0)