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

invig

v0.0.22

Published

Take a legacy JS or CoffeeScript codebase and automatically convert it to ES6 & standardjs.com

Downloads

122

Readme

Build Status

Here's another one of my more upsetting projects 👌

🌿 Invig

Breathes new life into legacy code bases by automatically:

  • Transpiling CoffeeScript to ES6
  • Transpiling ES5 to ES6 (without the stuff that recent Node hasn't nailed yet (e.g. we stick to require vs import for now))
  • Applying Standard linting with colon alignment for enhanced readability
  • Adding the necessary linting and building run-script boilerplate that the project can later independently use
  • Optionally checking for outdated or unused dependencies

Invig does this in a highly opinionated, non-configurable, and destructive way.

Let's have some fun breathing new life into your legacy project 😚 💨 🌿

Why

I'm dealing with an ever-growing number of projects that each have a slightly different setup, and I got pretty tired of context switching between ES5, ES6, CoffeeScript, and different code conventions across those projects.

The tools are there now to automate all difference away - it's just a matter of picking defaults and stringing those tools together. That's what Invig does. After successfully running Invig on your codebase, you can put your brain at ease thanks to uniformity, focus more on the work at hand, have a better time doing so thanks to syntactical goodness, while producing less bugs thanks to ESlint.

Why ditch ES5?

ES6 let's you express yourself in more powerful ways, typically meaning less boilerplate and more readable code.

Why ditch CoffeeScript?

While CoffeeScript lovers might agree already that uniform styling is pleasant and that ES6 is an upgrade over ES5, they might feel there are still a number of syntactical advantages CoffeeScript offers, missing from ES6. Our benchmark demo even results in lengthier ES6 code(!). While that may be true:

  • The syntactical sugar argument is losing ground with every ECMA iteration (1 a year now)
  • The ES6 ecosystem is vast. This results in more resources online, being able to attract more developers to help with your project, and linters like Flow and ESLint that can prevent more possible bugs and errors than CoffeeLint can.
  • If you can refrain from using import and async (Invig won't leverage these), recent Node.js can run your code without any transpiling. Meaning quicker developer iterations and less headaches.

Demo

Let's take a look at installing Invig at converting CoffeeScript to Standard compatible ES6 via STDIN

Install

Invig is meant to be run on a code base once (or a few times in one session). That's why it should not be used as a dependency but be installed globally instead.

npm install invig --global 

Use

⚠️ WARNING Changes are made in-place, make sure your code is protected by version control before using Invig.

Recursively port CoffeeScript/ES5 files to ES6 in-place:

invig -s ./src

Command line arguments

Usage: invig [options]

Options:

  -h, --help       output usage information
  -V, --version    output the version number
  -s, --src <dir>  Directory, file or pattern to convert
  -b, --bail       Abort on the first error instead of continuing to port next file
  -c, --check      When done, hunt for unused and un-updated dependencies
  -q, --quiet      Hide any output

More Examples

Port one ES5 file to ES6:

invig --src old-file.js

Port one CoffeeScript file to ES6 (deleting the old .coffee file.):

invig --src old-file.coffee

Optionally check for outdated or unused dependencies after the conversion completes:

invig --src src/ --check

Bail out as soon as Invig hits an error. By default Invig will continue processing the next file

invig --src src/ --bail

Do a dry run without changing any files (don't trust me, keep your stuff safe in Git):

invig --src src/ --dryrun

Apply Invig on a pattern (use quotes!)

invig --src 'src/**.js'

Transpile from STDIN

cat old-file.coffee | invig --src -

Workflow

The recommended way to use Invig is to:

  1. Be in master and have a clean Git working tree first
  2. git checkout -b es6
  3. Run Invig on your repo, point it to wherever your legacy sources live
  4. Apply manual fixes where the automation falls short (Invig and your build & test suite will tell you)
  5. Inspect the Git diff (I recommend the GitHub Desktop app for inspecting Invig's changes, even if you are a cli-god. Can't stress this enough) and repeat step 3 & 4
  6. Commit, push, send a PR for your es6 branch
  7. Have someone review the PR and merge it
  8. Let's celebrate that your codebase is now very much 2017 🍸

State

Invig is young, but as long as your code is in Git, feel free to have some fun with it, Invig has already ported some very large codebases.

Pre-1.0.0, we're allowing ourselves to make breaking changes at any release.

Gotchas

  • It's recommended to first make sure all CoffeeLint errors and warnings are fixed before porting your project.
  • Although Invig is destructive in nature, it currently leaves your build run script alone if you have already defined it. If you currently have CoffeeScript build tasks, remove them first, so that Invig can write the new one. The same goes for the lint, fix, and build:watch scripts, as well as the .eslintrc, and .babelrc files. The advantage of this that you can run Invig multiple times even though you have customized these components that are used in the modern setup.
  • ⚠️ WARNING Invig needs a sense of a project so that it can add ESLint config and similar, so from the first file you point it to, it traverses upwards to find a package.json, and modifies this in-place also.

Thanks to

I deserve no credit, Invig is just a tiny wrapper around these mastodons:

Invig in the Wild

Projects where Invig is used to breathe new life into old codebases:

Todo & Changelog

Please see CHANGELOG.md.

Contributing

Please see CONTRIBUTING.md.

Social Media

Welcoming discussion on:

Links

Authors & Contributors

License

Copyright (c) 2017 Kevin van Zonneveld. Licenses under MIT.