A set of Javascript utilities for building Node and browser apps.
The idea was to take all those small thing I'm always rewriting on every project and move them to a single package so I can, not only stop copying & pasting them all over the place, but also maintain them all together.
There are two rules I followed when I had to decide what to put and what to keep somewhere else:
The package is divided on 3 folders:
node: Utilities that are only compatible with Node.shared: Utilities that can work on both browser and Node.browser: Utilities that can only be used while on a browser.Two notes about the Node utilities:
This is a service to manage applications configurations. It takes care of loading, activating, switching and merging configuration files.
Read more about AppConfiguration
A really small service to centralize the place where you read environment variables and check if you are running on development or production.
Read more about EnvironmentUtils
Listens for uncaught exceptions and unhandled promises rejections, and logs them out with full detail.
The name leaves nothing to the imagination. As you may have guessed, this is service for logging messages into the console.
A tiny function that reads the contents of the app package.json. This is really useful on an Jimple application where you can register it, because the returned value gets cached and it's available as a service.
An easy way to manage locations and build paths relative to those locations on a Node app.
Is basically require but the path is relative to the project root directory.
A really basic client to work with an API endpoints requests.
Deep merge (and copy) of objects({}) and Arrays using native spread syntax.
Create a deferred promise using the native Promise object.
A small implementation of a pubsub service for handling events on an app.
A way to extend promise chains by injecting custom properties.
A set of utility functions to generate resources that can be used on Jimple or abstractions created from it (like Jimpex).
Read more about the Jimple Functions
A small collection of utility methods to work with objects.
An abstract class allows you to build services that relay on browser storage (session/local) and simplifies the way you work it.
All files are written using commonjs, as I targeted the oldest Node LTS and it doesn't support modules (without a flag) yet, but you can use it with ESM.
When the package gets published, an ESM version is generated on the path /esm. If you are using the latest version of Node, or a module bundler (like projext :D), instead of requiring from the package's root path, you should do it from the /esm sub path:
// commonjs
const ObjectUtils = require('wootils/shared/objectUtils');
// ESM
import ObjectUtils from 'wootils/esm/shared/objectUtils';
Since the next LTS to become "the oldest" is 12, which still uses the flag, I still have no plans on going with ESM by default.
| Task | Description |
|---|---|
docs | Generates the project documentation. |
lint | Lints the staged files. |
lint:all | Lints the entire project code. |
test | Runs the project unit tests. |
todo | Lists all the pending to-do's. |
I use husky to automatically install the repository hooks so the code will be tested and linted before any commit and the dependencies updated after every merge.
The configuration is on the husky property of the package.json and the hooks' files are on ./utils/hooks.
I use conventional commits with commitizen in order to support semantic releases. The one that sets it up is actually husky, that installs a script that runs commitizen on the git commit command.
The hook for this is on ./utils/hooks/prepare-commit-msg and the configuration for comitizen is on the config.commitizen property of the package.json.
I use semantic-release and a GitHub action to automatically release on NPM everything that gets merged to master.
The configuration for semantic-release is on ./releaserc and the workflow for the release is on ./.github/workflow/release.yml.
I use Jest to test the project.
The configuration file is on ./.jestrc.json, the tests are on ./tests and the script that runs it is on ./utils/scripts/test.
I use ESlint with my own custom configuration to validate all the JS code and the JSDoc comments.
The configuration file for the project code is on ./.eslintrc and the one for the tests is on ./tests/.eslintrc, and there's also an ./.eslintignore to exclude some files on the process. The script that runs it is on ./utils/scripts/lint.
I use JSDoc to generate an HTML documentation site for the project.
The configuration file is on ./.jsdoc.js and the script that runs it is on ./utils/scripts/docs.
I use @todo comments to write all the pending improvements and fixes, and Leasot to generate a report. The script that runs it is on ./utils/scripts/todo.
This project uses bash scripts for development, so if you want to develop on Windows, you need to do it with WSL.
FAQs
A set of Javascript utilities for building Node and browser apps.
The npm package wootils receives a total of 101 weekly downloads. As such, wootils popularity was classified as not popular.
We found that wootils demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Socket's package search now displays weekly downloads for npm packages, helping developers quickly assess popularity and make more informed decisions.
Security News
A Stanford study reveals 9.5% of engineers contribute almost nothing, costing tech $90B annually, with remote work fueling the rise of "ghost engineers."
Research
Security News
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.