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

@marknotton/dependencies

v1.0.10

Published

Instantiate all dev NPM packages into a single object and sanitise their names

Downloads

1

Readme

Dependencies for NPM

Made For NPM

Instantiate all dev NPM packages into a single object and sanitise their names.

Installation

npm i @marknotton/dependencies --save-dev
const dependencies =  require('@marknotton/dependencies')();

But why?

Code splitting tasks is ideal for maintaining your code in a coherent way, but in some cases it's useful to use the same instance of a node module without re-requested them within each task file. This is actually compulsory for things like Gulp, as it uses callbacks after each task completes, which can lose its scope if you attempt to redefine it more than once in multiple tasks.

This module will run through all the devDependencies from the package.json, sanitise their names, scope their vendors, and initialise them as getters.

Please note that this tool is tailored specifically to my needs and may not be suitable for everyone. If you think this package should be expanded with additional options, let me know.

How names are sanitised:

Scoped packages (normally starting with '@') will be nested into their vendor name.

Packages with the same module name as their vendor will still be nested (dependencies.rollup.rollup)

All names will lose their 'gulp-', 'postcss-', 'plugin-', and 'rollup-' prefixes and will be camel cased.

Some modules may have their names aliased into something else ('lumberjack' to 'log'), this is defined bespokely in this file.

Reserved Javascript names will not be sanitised.

Usage

Old method:

const dotenv = require("dotenv"),
      @doggistyle = require("@doggistyle/library"),
      lumberjack = require("@marknotton/lumberjack"),
      notifier = require("@marknotton/notifier"),
      svgToSymbols = require("@marknotton/svg-to-symbols"),
      autoprefixer = require("autoprefixer"),
      browserSync = require("browser-sync"),
      gulp = require("gulp"),
      concat = require("gulp-concat"),
      gulpif = require("gulp-if"),
      plumber = require("gulp-plumber"),
      postcss = require("gulp-postcss"),
      rename = require("gulp-rename"),
      terser = require("gulp-terser"),
      postcssCustomProperties = require("postcss-custom-properties"),
      rollup = require("rollup"),
      rollupPluginCommonjs = require("@rollup/plugin-commonjs"),
      rollupPluginMultiEntry = require("@rollup/plugin-multi-entry"),
      rollupPluginNodeResolve = require("@rollup/plugin-node-resolve"),
      postcssAssets = require("postcss-assets"),
      snowpack = require("snowpack")

New method:

const dependencies = require('./gulp/dependencies')
  
const {
  doggistyle : { core, library },
  marknotton : { log, notifier, svgToSymbols },
  postcss : { customProperties, assets },
  rollup : { rollup, commonjs, multiEntry, nodeResolve },
  dotenv, browserSync, gulp, concat, if, plumber, rename, terser, snowpack
} = dependencies

Remember this is not about syntactic sugar, this about retaining the scope of all the packages across all my tasks by only instantiating them once.

Aliases

Some packages may need a bespoke reference to avoid conflicts or simply to sanitise the name to something that's easier to use. 'aliases' in your package.json

file should have the original name as the key, and the new desired name as the value.

It's possible to break the scoped vendor nesting by setting aliases if necessary.

"aliases": {
  "@marknotton/lumberjack": "log",
  "gulp-run-command": "run",
  "gulp-if": "gulpif",
  "vinyl-source-stream": "source",
  "@rollup/stream": "rollup",
  "@rollup/plugin-node-resolve": "@rollup/resolve",
  "@rollup/plugin-multi-entry": "@rollup/multi"
}

Options

log (Bool) ( default: true ) - An output of all the package aliases and how to destructure the export will be logged. Only works in 'dev' environments.

scope (Bool) ( default: true ) - Scoped vendors will be nested in the final export. If false, the export will be flattened but may cause naming conflicts.

moduleHandler (Function)(defaults : @see "Request Module" in this modules index.js) - Handle special changes to certain dependencies; like instantiating a modules sub-method with a custom settings.

nameTruncators (Array) ( default : ['gulp-', 'postcss-', 'plugin-', 'rollup-'] ) - Remove parts of the common vendor names to help sanitise the names how you'd like. You can completely edit the name using the "aliases" settings in your package.json or as another option (see below).

aliases (Object) - This serves the same functionality as the aliases setting describe further up this page. Defining the aliases in this option will prioritised over the package.json settings.

const dependencies =  require('@marknotton/dependencies')({ 
  scope : false, 
  log : false,
  moduleHandler : module => {
    if ( module == 'someModule' ) {
      return require(module).default({...})
    }
  },
  nameTruncators : [ 'webpack-' ],
  aliases : { "vinyl-source-stream": "source" }
});

Default Packages

Since Node's Path, Stream, and File System (fs) API's are so commonly used, these are always included in the dependancy list; with 'Path' and 'Stream' references titlecased to differentiate them from the users package dependencies. Also Lumberjack has been added to the default packages list with the alias 'log'.

const { Path, Stream, fs } = require('@marknotton/dependencies')()