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

safejs-cli

v1.0.2

Published

A safe offensive javascript, finally!

Downloads

2

Readme

SafeJS

A safe javascript, finally!

Installation

npm install safejs-cli --save-dev

Usage

General idea

What if we could simply write safe in front of an unsafe bit of code to make it safe. No surrounding validation, no try / catch, no worries, just like that.

Well now you can. ⚡

Dealing with unpredictable data structures

Previously in Vanilla JS:

// Accessing deeply nested variables in a safe way quickly gets messy
if (response &&
  response.data &&
  response.data.user &&
  response.data.user[0] &&
  response.data.user[0].id
) {
  console.log(response.data.user[0].id);
}

Equivalent in SafeJS:

// Not anymore
console.log(safe response.data.user[0].id);

Previously in Vanilla JS:

let id;
if (response &&
  response.data &&
  response.data.user &&
  response.data.user[0] &&
  response.data.user[0].id
) {
  id = response.data.user[0].id;
}

Equivalent in SafeJS:

// Note that the `( ... )` are important here to limit the context appropriately
const id = (safe response.data.user[0].id);

Previously in Vanilla JS:

// It also works with unsafe conditions
if (response &&
  response.data &&
  response.data.user &&
  response.data.user[0] &&
  response.data.user[0].id &&
  response.data.user[0].id !== 'unknown'
) {
  console.log('found');
}

Equivalent in SafeJS:

if (safe response.data.user[0].id !== 'unknown'){
  console.log('found');
}

Previously in Vanilla JS:

// It also works with unsafe functions
let res;
try {
  res = await axios.get('url/does/not/exist');
} catch (err) {}
console.log(res); // undefined

Equivalent in SafeJS:

const res = (safe await axios.get('url/does/not/exist'));
console.log(res); // undefined

Managing the context of execution

By default SafeJS will assume that when you write safe ... you are talking about the largest context of execution (aka the closest (...)). Unless you are running in an explicit context already, make sure you always specify the context around safe when using it.

Also note that SweetJS, the compiler used by SafeJS, is not very friendly with semicolons, it will fail to interprete the context in some edges cases (chaining of function declarations, chaining of function executions and function declarations). To be safe, always write your semicolons.

Here is a couple of example:

if (safe a.b) {} // valid
if (safe a.b && c.d) {} // valid
if (safe a.b && safe c.d) {} // invalid
if ((safe a.b) && (safe c.d)) {} // valid

console.log(safe a.b); // valid
console.log(safe a.b, c); // invalid
console.log((safe a.b), c); // valid

const a = safe b.c; // invalid
const a = (safe b.c); // valid

const b = safe foo(); // invalid
const b = (safe foo()); // valid

Transpile

From your root directory, run:

safejs

This will transpile your code into a folder named predist.

You can now run the entry point of your code in this folder to see it in action.

Hint: Customize your start script and soon you won't event remember this command

Configure

You can configure SafeJS using these optional flags if necessary:

safejs --inputDir=./src --outputDir=./predist --noBabel=true --log=false

You can also use a safejs.config.js file at root level to specify your config if a few additional options:

module.exports = {
  inputDir: './src',
  outputDir: './predist',
  noBabel: true,
  log: false,
  exclude: [
    /.+(.ghost.js)/g,
    /(excluded)/i,
  ]
}

Note: exclude is an array of regular expressions for paths to exclude

Working with Webpack, Babel and Testing

Simply set your source directory to ./predist (or custom directory) instead of ./src. Easy.

Note: For now SweetJS does not allow direct input manipulation, which prevents me from making a Webpack loader (would remove the need for a pre-distribution). In a further version I might fork SweetJS's compiler directly to allow it and make a custom loader.

Hot reload

If you want hot reload you can do so using Nodemon

Hint: Customize your start and build scripts to transpile your code before running it