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 🙏

© 2025 – Pkg Stats / Ryan Hefner

pligrate

v0.1.0

Published

Prettier should be run after a successful migration

Downloads

10

Readme

Running Prettier

Prettier should be run after a successful migration

$ prettier --print-width 120 --single-quote --trailing-comma es5 --write components/**/**/*.jsx

TODO

High

  • [ ] publish this
  • [ ] make this into a gulp plugin?
  • [x] have the script create a manifest instead of logging out what files need to be fixed
  • [x] come up with a way to prevent files from being overwritten
  • [x] migrating can be a little flaky at times
  • [x] deeply nested components are not being written
  • [x] finish prettier ignore list
  • [x] handle partials with attributes
  • [x] Improve handling ignored files, ie files with markdown

Medium

  • [ ] component import paths may not be correct
  • [ ] improve handling props (where does data come from, how should it be passed to components)
  • [ ] think about productizing this and writing a blog post
  • [x] improve this to migrate only one file at a time or entire directories..

Low

  • [x] prefer .jsx over .js
  • [ ] shorthand fragments
  • [ ] prefer named components over anon and export after the definition and should set the component display name
  • [ ] file naming should be pascal case
  • [ ] finish compileIfEqual compiler
  • [ ] write tests
  • [ ] Handle #carouselIterator
  • [ ] handle with blocks
  • [ ] better fix for inline if
  • [ ] inline partials
  • [ ] handle partials with children

Known Issues

Props

The compiler is unaware of the shape of our yaml files, thus, it makes a lot of assumptions about what data to render in components. Additionally, when the compiler encounters Panini helpers it begins to breakdown even further as it does not have any knowledge of data is used throughout the website.

For example, in src/partials/collage.html Panini refers to the iterable as this which does not transpile well to javascript. An example is illustrated below:

src/partials/collage.html

  <div class="collage">
    {{#each this.collage}}
      <div class="collage__item collage__item--{{grid-item}}">

        {{#ifequal this.item-type 'modal'}}
          <div class="collage__image collage__image--ix modal-trigger" data-open="collage-modal">
            <img class="lazy" data-src="{{img-url}}" alt="{{alt-text}}">
          </div>
        {{/ifequal}}

        <!-- all other code omitted -->
    {{/each}}
</div>

is compiled to:

src/components/collage.js

<div className="collage">
    {props.collage.map((item, i) => <React.Fragment key={i}>      <div className={"collage__item collage__item--" + item['grid-item']}>

        {this['item-type'] === 'modal' && ( 
          <div className="collage__image collage__image--ix modal-trigger" data-open="collage-modal">
            <img className="lazy" data-src={item['img-url']} alt={item['alt-text']} />
          </div>
         )}
    )}
</div>

Manual intervention and cross-referencing the yaml passed to this file is required to correct bugs such as this. Assuming that props is passed as <Collage collage={props.impact} />, the solution would be:

<div className="collage">
    {props.collage.map((item, i) => <React.Fragment key={i}>      <div className={"collage__item collage__item--" + item['grid-item']}>

        {item['item-type'] === 'modal' && ( 
          <div className="collage__image collage__image--ix modal-trigger" data-open="collage-modal">
            <img className="lazy" data-src={item['img-url']} alt={item['alt-text']} />
          </div>
         )}
    )}
</div>

Inline If

When transpiling inline if conditions such as:

<div class="static-data-table {{if no-top-padding 'static-data-table--no-top-padding'}}">

The result ends up like:

<div className="static-data-table { props['no-top-padding'] ? 'static-data-table--no-top-padding' : null}">

and will need manual intervention:

<div className={`static-data-table ${props['no-top-padding'] ? 'static-data-table--no-top-padding' : null}`>