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

xk6-common-util

v1.0.6

Published

This library offers a collection of utility functions and modules that address common funcunalities that are used across other related projects.

Downloads

6

Readme

xk6-common-utils

[[TOC]]

Summary

This library offers a collection of utility functions and modules that address common funcunalities that are used across other related projects.

Component Owner

The components in the repository are being maintained by

Dependencies

The following table lists all dependencies of the component.

  • Source: This component (use the container name).

  • Target: The used component (use the container name).

  • Protocol: Specify the protocol used for the dependency: REST, JMS, AMQP, SQL, erc.

  • Purpose: Specify for what the dependency is used - and maybe also when (e.g. if only during installation).

  • Error Detection: Describe what symptoms indicate that the dependency is broken.

  • Troubleshooting: Describe what is required to fix issues (typically something like 'restart target' or 'restart both').

    Beware:

    • Make sure that table is exactly in the given format and that it is enclosed by <!-- Dependencies -->.
    • This is imperative for the tooling which extracts the contents of all those tables and creates the dependency overview and matrix.

    | Source | Target | Protocol | Purpose | Error Detection | Troubleshoot | | ----------- | ----------- | -------- | ------------------------------------ | ------------------------------------- | ------------------- | | Container A | Container B | REST | Describe for why A needs B and when. | Ex: logs, not working functions, etc. | Ex: restart target. | | Container A | Container C | SQL | Describe for why A needs C and when. | Ex: logs, not working functions, etc. | Ex: restart target. |

    Notes:

    • If and only if the container name is not unique between region and central, use container(region) and container(central).
    • Container name in Target and Source cannot contain spaces`.

Customizing

This section describes configuration which can be done by operations. All configuration will be retained during upgrades.

{Describe only configuration which can (or has to be) done by operations. Please be aware that this configuration also has to be maintained, e.g. may not be lost during an update.}

{If you don't have any configuration like this, write: This component does not provide any configuration for operations.}

{Config 1}

{Describe config item, what it is about and where/how it can be configured.}

{Config 2}

{Describe config item, what it is about and where/how it can be configured.}

{Config n}

Monitoring

This section describes how to best check and monitor the state of the component.

Healthchecks

{Describe when the component is healthy - and possible root causes when it is unhealthy}

{Mention if there are special things to do to check further (no need to mention no-brainers)}

Grafana Dashboards

All components provide generic metrics which can be found in Grafana dashboards. Please refer to general monitoring section.

{Add information about dashboard specific to the component/service}

Troubleshooting

This section gives hints with respect to troubleshooting.

Logging

{Describe log-index used in Kibana } {Describe where to find other logging sinks, e.g. of wildfly, keycloak etc} {Describe how to increase the logging level if applicable. Also mention explicitly that this change shall be reverted after analysis!}

Error Handling

{Describe what can be done in case the component is in error. Be as concrete as possible. Which errors can an operator come across? How can she analyze them further, what can she do about it?}

Known Limitations

This section lists known limitations of the service:

  • {Ado-Link or Title of Issue 1}
  • {Ado-Link or Title of Issue 2}
  • {Ado-Link or Title of Issue n}

{Only use for things which are NOT part of the release notes anyways. Examples: The need to use an API instead of UI to do some configuration, or a missing, but already planned observability feature... Anything where operations might think it should be there, but is not.}

Developer Information

{Use this for everything else, e.g. also developer configuration, pipelines, debug etc. }