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

@rjhilgefort/export-dir

v2.0.0

Published

Declarative `index.js` builder for exporting files in the same directory.

Downloads

725

Readme

@rjhilgefort/export-dir

Declarative index.js builder for exporting files in the same directory.

This tiny package removes the maintenance of updating index.js files that simply require and export all of the files in the same directory to allow for a deconstuctable interface of the folder.

npm version Build Status dependencies devDependencies Status MIT Licence PRs Welcome

Installation

yarn add @rjhilgefort/export-dir
npm install --save @rjhilgefort/export-dir

Docs

Two functions/modes of operation and both are autocurried, so you can call them however you would like (with a caveat being that you must call it will all parameters).

fromFiles

Allows you to apply a transformation on the file name as the exported key.

fromFiles :: (String -> String) => String<Dir> -> Object
fromFiles :: (transformation, path) => ({ })

fromExports

Allows you to apply a transformation on the exports of the file as the exported key.

fromExports :: (* -> String) => String<Dir> -> Object
fromExports :: (transformation, path) => ({ })

Behavior

Something more formal will come, but for now, here's some notes about the behavior. This applies to all methods/modes of operation.

  • General
    • All .js and .json files will be exported.
    • *.test.js files will be ignored.
    • index.js will be ignored.
  • fromFiles
    • lodash.camelcase is the default transformation.
  • fromExports
    • The name property of the export is the default transformation.
    • If a key can not be determined, that file/export is omitted from the results (see tests/mocks).

Usage

Files names as subject for transforms to keys

// Basic one-liner
module.exports = require('@rjhilgefort/export-dir').fromFiles(null, __dirname);

// With `transform` (this is the default)
const camelCase = require('lodash.camelcase');
const { fromFiles } = require('@rjhilgefort/export-dir');
module.exports = fromFiles(camelcase, __dirname);

// With Custom `transform`
const { compose } = require('ramda');
const camelCase = require('lodash.camelcase');
const upperFirst = require('lodash.upperfirst');
const { fromFiles } = require('@rjhilgefort/export-dir');
module.exports = fromFiles(compose(upperFirst, camelCase), __dirname);

Exports as subject for transforms to keys

// Folder of classes one-liner
module.exports = require('@rjhilgefort/export-dir').fromExports(null, __dirname);

// Folder of classes, with `transform` (this is the default)
const { prop } = require('ramda');
const { fromExports } = require('@rjhilgefort/export-dir');
module.exports = fromExports(prop('name'), __dirname);

// Folder of similarly structured objects: `{ constant: 'identifier' }`
const { prop } = require('ramda');
const { fromExports } = require('@rjhilgefort/export-dir');
module.exports = fromExports(prop('constant'), __dirname);

Problem / Solution

Imagine we have the following project.

/
  app.js
  lib/
    foo.js
    foo.test.js
    bar.js
    bar.test.js
    baz.js
    baz.test.js
    index.js

We want to make sure we're keeping our functions isolated, testable, and generic, so we created a lib folder to keep them. This also has the advantage of keeping our app.js clean of helper methods and just focusing on what it, specifically, wants to do.

We want to avoid doing this:

// app.js
const foo = require('./lib/foo')
const bar = require('./lib/bar')
const baz = require('./lib/baz')
// ...

So we create lib/index.js that rexports everything...

// lib/index.js
module.exports = {
  foo: require('./foo'),
  bar: require('./bar'),
  baz: require('./baz'),
}

Great. New we can change our app.js file to deconstruct the methods from the folder require.

// app.js
const { foo, bar, baz } = require('./lib');
// ...

We're done, except that this is a pain to maintain. Every time we add a new method, we have to go update our index file. If we forget, we'll have a runtime error when trying to deconstruct our new method in app. This package aims to solve the problem by allowing you to setup rules for how the index file should be built, and then not having to worry about it anymore.

Here's what our lib/index.js and app.js looks like when using @rjhilgefort/export-dir:

// lib/index.js
const { fromFiles } = require('@rjhilgefort/export-dir');
module.exports = fromFiles(null, __dirname);

// app.js
const { foo, bar, baz } = require('./lib');

Q & A

Who cares about CommonJS modules anymore?

Though ES modules in Node.js is right around the corner, this is still a pattern that will likely be around in legacy code for some time.

Why does this need to exist when there's others that have implemented the same thing, and with more features?

I didn't find one that had everything I wanted and I didn't want to work in their respective code bases.