profile
viewpoint
Colin Ihrig cjihrig Pittsburgh, PA node.js tsc, libuv collaborator, hapi.js tsc. also does things with wasm/wasi and grpc

autopilotpattern/postgres 14

Implementation of the Autopilot Pattern for Postgres

cjihrig/bcrypt.wasm 11

bcrypt in WebAssembly

cjihrig/artificial 9

Inject fake HTTP request/response into an Express server

cjihrig/belly-button 8

The best source for lint

cjihrig/augmented-interval-tree 2

Augmented interval tree implementation with no dependencies

autopilotpattern/ghost 1

Implementation of the Autopilot Pattern for Ghost

cjihrig/borland 1

hapi plugin for working with toolbag

cjihrig/625 0

Babel 6 convenience wrapper

cjihrig/accept 0

HTTP Accept-* headers parsing

cjihrig/address 0

Validate email addresses

PullRequestReviewEvent

delete branch cjihrig/node

delete branch : libuv

delete time in 19 hours

created taghapijs/beam

tagv2.0.1

HTTP benchmark API

created time in 20 hours

release hapijs/beam

v2.0.1

released time in 20 hours

created taghapijs/jwt

tagv2.0.1

JWT (JSON Web Token) Authentication

created time in 20 hours

release hapijs/jwt

v2.0.1

released time in 20 hours

push eventhapijs/jwt

cjihrig

commit sha d3dd22c1b8e2b4bac19250c665d44896ad14357a

update to lab@24.x.x

view details

cjihrig

commit sha e19d2914959f1a642be32d3827a0151ef6c4ee3b

v2.0.1

view details

push time in 20 hours

push eventhapijs/jwt

Devin Stewart

commit sha 8aa4dedc051dac7c794f9e19e4e1ad9cfff49fde

Changes to README.md to align with other modules in the family

view details

push time in 20 hours

PR merged hapijs/jwt

Changes to README.md to align with other modules in the family

I created this as a separate PR from the API.md #19 as there are references to the website and I don't know how this ties all together. #15

+10 -0

0 comment

1 changed file

devinstewart

pr closed time in 20 hours

created taghapijs/bell

tagv12.1.1

Third-party login plugin for hapi

created time in 20 hours

release hapijs/bell

v12.1.1

released time in 20 hours

push eventhapijs/bell

cjihrig

commit sha b6569e8d6a3782a82ed8d1fc004cda0375fbe884

v12.1.1

view details

push time in 21 hours

created taghapijs/ratrace

tagv1.0.2

Frameworks performance comparison

created time in 21 hours

release hapijs/ratrace

v1.0.2

released time in 21 hours

push eventhapijs/ratrace

cjihrig

commit sha c95a1394ba0adf4a468a6ee47fa4620bbee7539d

v1.0.2

view details

push time in 21 hours

created taghapijs/crumb

tagv8.0.1

CSRF crumb generation and validation for hapi

created time in 21 hours

release hapijs/crumb

v8.0.1

released time in 21 hours

push eventhapijs/crumb

cjihrig

commit sha 4441d44df5a9f66876028a49eaa916d2d4b853e7

v8.0.1

view details

push time in 21 hours

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

PR opened nodejs/node

tools: update ESLint to 7.10.0

Update ESLint to 7.10.0

Checklist
  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [x] commit message follows commit guidelines
+160 -1002

0 comment

26 changed files

pr created time in a day

create barnchcjihrig/node

branch : eslint

created branch time in a day

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

push eventhapijs/beam

cjihrig

commit sha 2e39c5a9ae0d46af14a65c8408725b3295ace843

update to lab@24.x.x

view details

cjihrig

commit sha 280705efa4485a08c8322dfd7738ac2199874e56

v2.0.1

view details

push time in a day

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

created taghapijs/inert

tagv6.0.3

Static file and directory handlers for hapi.js

created time in a day

release hapijs/inert

v6.0.3

released time in a day

created taghapijs/good-console

tagv9.0.1

Console reporting for Good process monitor

created time in a day

release hapijs/good-console

v9.0.1

released time in a day

push eventhapijs/inert

cjihrig

commit sha e8ad66b63670d7445db5e781e4efeec3edbc3e52

update to lab@24.x.x

view details

cjihrig

commit sha 28b4caa6a6d9dc6ad45a88966fe767cd7d2261ca

v6.0.3

view details

push time in a day

created taghapijs/catbox-redis

tagv6.0.2

Redis adapter for catbox

created time in a day

release hapijs/catbox-redis

v6.0.2

released time in a day

push eventhapijs/good-console

cjihrig

commit sha 7019e2a43cdacde864af20929a7129214a9e32c6

update to lab@24.x.x

view details

cjihrig

commit sha 23699f2a251706aa60802bf4e0fea18888522a40

v9.0.1

view details

push time in a day

created taghapijs/good

tagv9.0.1

hapi process monitoring

created time in a day

release hapijs/good

v9.0.1

released time in a day

push eventhapijs/catbox-redis

cjihrig

commit sha a1a34442170fc4278825ac4a2952ffbad9b552b7

update to lab@24.x.x

view details

cjihrig

commit sha ae8b576955a6df22001e0d58f97eafaf875eacf2

v6.0.2

view details

push time in a day

created taghapijs/cookie

tagv11.0.2

Cookie authentication plugin

created time in a day

release hapijs/cookie

v11.0.2

released time in a day

push eventhapijs/good

cjihrig

commit sha 26ef30cf1ea7f45fc1ed091d7008c6a06ee60ee5

update to lab@24.x.x

view details

cjihrig

commit sha 3a8f3ef07e6284753c57e26089ad53ebfcfc6d21

v9.0.1

view details

push time in a day

created taghapijs/h2o2

tagv9.0.2

Proxy handler for hapi.js

created time in a day

release hapijs/h2o2

v9.0.2

released time in a day

push eventhapijs/cookie

cjihrig

commit sha 8d6edf305f90281ab595fee3660780cf5457c112

update to lab@24.x.x

view details

cjihrig

commit sha a56bbf801049eb6923ce2964398fbb14cab537ab

v11.0.2

view details

push time in a day

created taghapijs/nes

tagv12.0.4

WebSocket adapter plugin for hapi routes

created time in a day

release hapijs/nes

v12.0.4

released time in a day

push eventhapijs/h2o2

cjihrig

commit sha 6c1f9743c917b8e1d39f828a66f03c026bbe3d9e

update to lab@24.x.x

view details

cjihrig

commit sha a1db8d2affa425cfa085d0f2c2e42e7a8b458ee5

v9.0.2

view details

push time in a day

push eventcjihrig/h2o2

Lloyd Benson

commit sha 5165cd8d299630c61faad0f194757978dfe9833d

migrate to new travis format (#121)

view details

cjihrig

commit sha 6c1f9743c917b8e1d39f828a66f03c026bbe3d9e

update to lab@24.x.x

view details

cjihrig

commit sha a1db8d2affa425cfa085d0f2c2e42e7a8b458ee5

v9.0.2

view details

push time in a day

push eventhapijs/nes

cjihrig

commit sha 5694fdcd67e7273ee92b0d4d8b393d76a8d28199

update to lab@24.x.x

view details

cjihrig

commit sha 9b4c4b2e3814bb8b68ce43b33c00a8784e4d38b1

v12.0.4

view details

push time in a day

created taghapijs/scooter

tagv6.0.1

User-agent information plugin for hapi

created time in a day

release hapijs/scooter

v6.0.1

released time in a day

push eventhapijs/scooter

cjihrig

commit sha e0adad692b1d1c99bedd3f502d37eabb0c47473e

update to lab@24.x.x

view details

cjihrig

commit sha 2233e18e0198afab746ef59708295b13ac1b3673

v6.0.1

view details

push time in a day

PR closed nodejs/node

Merge pull request #1 from nodejs/master

lol

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [ ] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [ ] tests and/or benchmarks are included
  • [ ] documentation is changed or added
  • [ ] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

+0 -0

0 comment

0 changed file

gagominecraft12

pr closed time in 2 days

issue commenthapijs/hapi

unable to set 'Content-Encoding', 'gzip' for a compressed response object even after setting header via reply.response

Please provide runnable examples - ideally as minimal as possible. Your chances of receiving help will be significantly higher.

meeravalishaik

comment created time in 2 days

issue commenthapijs/hapi

getting method did not return a value, a promise, or throw an error when sending a compressed response

From what I can tell, this works:

'use strict';
const Util = require('util');
const Zlib = require('zlib');
const Hapi = require('@hapi/hapi');
const compress = Util.promisify(Zlib.gzip);

async function main() {
  const server = Hapi.server({
    port: 4000,
    host: '0.0.0.0'
  });

  server.route({
    method: 'get',
    path: '/',
    handler: (request) => {
      const data = { foo: 'bar' };

      return compress(JSON.stringify(data));
    }
  });

  await server.start();
}

main();
meeravalishaik

comment created time in 2 days

Pull request review commenthapijs/.github

Add initial documentation on issue, PR, and release maintenance

+# Maintenance+This document outlines basic procedures for maintenance of issues, PRs, and releases.++## Issues and Pull Requests+Issues and pull requests are at the core of hapi's approach to documentation and messaging to the broader community.  They are rigorously labeled, associated with releases, and assigned to collaborators responsible for their resolution.  Official discussions, release notes, announcements, and community support all generally take the form of issues.  Finally, the source of truth for our changelogs are also managed through issues.++### Labels+Labels are standardized through [organization defaults](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-default-labels-for-repositories-in-your-organization).  Here are some notable ones:+ - `support` - requests for clarification or help.+ - `bug` - reports of unintended behavior.+ - `security` - indication of security implications.+ - `feature` - requests for new functionality.+ - `release notes` - documentation of changes in major releases, sometimes accompanied by a migration guide.+ - `documentation` - non-code related changes to the readme, API docs, or similar.+ - `dependency` - changes to underlying or peer dependencies.+ - `breaking changes` - indication of a breaking change in behavior, principally for major releases.+ - `help wanted` - signals that it's welcome for any community member to offer a PR or otherwise help to resolve the issue.++Every issue and pull request should have at least one label attributed to it.  The labels for an issue may change over time.  When a pull request addresses a particular issue, it will often have the same labels as that issue.++### The Connection to Releases+We associate PRs and issues to released versions of our modules in order to leave a paper trail for users that includes code, documentation, and discussion.  It can also be interpreted programmatically to e.g. display automatically-generated changelogs on the website as can be seen [here for boom](https://hapi.dev/module/boom/changelog/).++#### Milestones+When a PR is merged or issue is closed, it should be associated with a [milestone](https://github.com/hapijs/hapi/milestones) for the version of the module in which the corresponding work will be released.  All merged PRs should be associated with a milestone, and all issues resolved by a merged PR or a commit should have a milestone.  Milestones are named by the full semver version of the release, e.g. `2.1.0`, `0.1.1`, `9.0.0`.  When the version is published, that milestone should be closed.  There should never be zero open milestones for a given module: when one milestone is closed, a new one is created for the next patch version.  For example, once `2.1.0` is released then the milestone for that version will be closed and a new milestone for `2.1.1` will be created.++#### Release Notes+It is encouraged to write-up an issue with release notes for major changes, especially for modules that are intended to be used externally to the organization (e.g. hapi, bell, nes) versus hapi core (e.g. pez, topo, shot).  The [hapijs/hapi](https://github.com/hapijs/hapi) repository should have release notes for every major version of the framework.  [This](https://github.com/hapijs/hapi/issues/4017) is a great example of typical release note format and ideal level of detail.++### Assignees+The collaborator responsible for final review and merge of pull requests should mark themselves as the "assignee."  This leaves an at-a-glance paper trail primarily for convenience ("who understands the changes made in #365?"), and is in recognition of that person's involvement/contribution.  When a collaborator closes an issue that they were responsible for resolving (e.g. answered a user's support question), they may also mark themselves as the assignee.++### Closing+> _This list is not meant to indicate anything about the numerous other cases that may occur, it is meant only to offer some guidelines._++ - Support issues without any response should remain open for two weeks then may be closed.+ - If a support issue doesn't contain a sufficient reproduction it may be closed immediately with a comment.+ - Any effort at resolving a support issue makes it eligible for being closed.  It's useful to point folks to the hapi hour slack for further support.

Maybe indicate that discussion can continue on a closed issue.

devinivy

comment created time in 2 days

Pull request review commenthapijs/.github

Add initial documentation on issue, PR, and release maintenance

+# Maintenance+This document outlines basic procedures for maintenance of issues, PRs, and releases.++## Issues and Pull Requests+Issues and pull requests are at the core of hapi's approach to documentation and messaging to the broader community.  They are rigorously labeled, associated with releases, and assigned to collaborators responsible for their resolution.  Official discussions, release notes, announcements, and community support all generally take the form of issues.  Finally, the source of truth for our changelogs are also managed through issues.++### Labels+Labels are standardized through [organization defaults](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-default-labels-for-repositories-in-your-organization).  Here are some notable ones:+ - `support` - requests for clarification or help.+ - `bug` - reports of unintended behavior.+ - `security` - indication of security implications.+ - `feature` - requests for new functionality.+ - `release notes` - documentation of changes in major releases, sometimes accompanied by a migration guide.+ - `documentation` - non-code related changes to the readme, API docs, or similar.+ - `dependency` - changes to underlying or peer dependencies.+ - `breaking changes` - indication of a breaking change in behavior, principally for major releases.+ - `help wanted` - signals that it's welcome for any community member to offer a PR or otherwise help to resolve the issue.++Every issue and pull request should have at least one label attributed to it.  The labels for an issue may change over time.  When a pull request addresses a particular issue, it will often have the same labels as that issue.++### The Connection to Releases+We associate PRs and issues to released versions of our modules in order to leave a paper trail for users that includes code, documentation, and discussion.  It can also be interpreted programmatically to e.g. display automatically-generated changelogs on the website as can be seen [here for boom](https://hapi.dev/module/boom/changelog/).++#### Milestones+When a PR is merged or issue is closed, it should be associated with a [milestone](https://github.com/hapijs/hapi/milestones) for the version of the module in which the corresponding work will be released.  All merged PRs should be associated with a milestone, and all issues resolved by a merged PR or a commit should have a milestone.  Milestones are named by the full semver version of the release, e.g. `2.1.0`, `0.1.1`, `9.0.0`.  When the version is published, that milestone should be closed.  There should never be zero open milestones for a given module: when one milestone is closed, a new one is created for the next patch version.  For example, once `2.1.0` is released then the milestone for that version will be closed and a new milestone for `2.1.1` will be created.

It might be worth adding a sentence stating that if things aren't part of a milestone, they won't show up on the website. That was unpleasant to discover the hard way 😄

devinivy

comment created time in 2 days

Pull request review commenthapijs/.github

Add initial documentation on issue, PR, and release maintenance

+# Maintenance+This document outlines basic procedures for maintenance of issues, PRs, and releases.++## Issues and Pull Requests+Issues and pull requests are at the core of hapi's approach to documentation and messaging to the broader community.  They are rigorously labeled, associated with releases, and assigned to collaborators responsible for their resolution.  Official discussions, release notes, announcements, and community support all generally take the form of issues.  Finally, the source of truth for our changelogs are also managed through issues.++### Labels+Labels are standardized through [organization defaults](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-default-labels-for-repositories-in-your-organization).  Here are some notable ones:+ - `support` - requests for clarification or help.+ - `bug` - reports of unintended behavior.+ - `security` - indication of security implications.+ - `feature` - requests for new functionality.+ - `release notes` - documentation of changes in major releases, sometimes accompanied by a migration guide.+ - `documentation` - non-code related changes to the readme, API docs, or similar.+ - `dependency` - changes to underlying or peer dependencies.+ - `breaking changes` - indication of a breaking change in behavior, principally for major releases.+ - `help wanted` - signals that it's welcome for any community member to offer a PR or otherwise help to resolve the issue.++Every issue and pull request should have at least one label attributed to it.  The labels for an issue may change over time.  When a pull request addresses a particular issue, it will often have the same labels as that issue.++### The Connection to Releases+We associate PRs and issues to released versions of our modules in order to leave a paper trail for users that includes code, documentation, and discussion.  It can also be interpreted programmatically to e.g. display automatically-generated changelogs on the website as can be seen [here for boom](https://hapi.dev/module/boom/changelog/).
We associate PRs and issues to released versions of our modules in order to leave a paper trail for users that includes code, documentation, and discussion.  It can also be interpreted programmatically to e.g. display automatically generated changelogs on the website as can be seen [here for boom](https://hapi.dev/module/boom/changelog/).
devinivy

comment created time in 2 days

Pull request review commenthapijs/.github

Add initial documentation on issue, PR, and release maintenance

+# Maintenance+This document outlines basic procedures for maintenance of issues, PRs, and releases.++## Issues and Pull Requests+Issues and pull requests are at the core of hapi's approach to documentation and messaging to the broader community.  They are rigorously labeled, associated with releases, and assigned to collaborators responsible for their resolution.  Official discussions, release notes, announcements, and community support all generally take the form of issues.  Finally, the source of truth for our changelogs are also managed through issues.++### Labels+Labels are standardized through [organization defaults](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-default-labels-for-repositories-in-your-organization).  Here are some notable ones:+ - `support` - requests for clarification or help.+ - `bug` - reports of unintended behavior.+ - `security` - indication of security implications.+ - `feature` - requests for new functionality.+ - `release notes` - documentation of changes in major releases, sometimes accompanied by a migration guide.+ - `documentation` - non-code related changes to the readme, API docs, or similar.
 - `documentation` - non-code related changes to the README, API docs, or similar.
devinivy

comment created time in 2 days

Pull request review commenthapijs/.github

Add initial documentation on issue, PR, and release maintenance

+# Maintenance+This document outlines basic procedures for maintenance of issues, PRs, and releases.++## Issues and Pull Requests+Issues and pull requests are at the core of hapi's approach to documentation and messaging to the broader community.  They are rigorously labeled, associated with releases, and assigned to collaborators responsible for their resolution.  Official discussions, release notes, announcements, and community support all generally take the form of issues.  Finally, the source of truth for our changelogs are also managed through issues.++### Labels+Labels are standardized through [organization defaults](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-default-labels-for-repositories-in-your-organization).  Here are some notable ones:+ - `support` - requests for clarification or help.+ - `bug` - reports of unintended behavior.+ - `security` - indication of security implications.+ - `feature` - requests for new functionality.+ - `release notes` - documentation of changes in major releases, sometimes accompanied by a migration guide.+ - `documentation` - non-code related changes to the readme, API docs, or similar.+ - `dependency` - changes to underlying or peer dependencies.+ - `breaking changes` - indication of a breaking change in behavior, principally for major releases.+ - `help wanted` - signals that it's welcome for any community member to offer a PR or otherwise help to resolve the issue.++Every issue and pull request should have at least one label attributed to it.  The labels for an issue may change over time.  When a pull request addresses a particular issue, it will often have the same labels as that issue.++### The Connection to Releases+We associate PRs and issues to released versions of our modules in order to leave a paper trail for users that includes code, documentation, and discussion.  It can also be interpreted programmatically to e.g. display automatically-generated changelogs on the website as can be seen [here for boom](https://hapi.dev/module/boom/changelog/).++#### Milestones+When a PR is merged or issue is closed, it should be associated with a [milestone](https://github.com/hapijs/hapi/milestones) for the version of the module in which the corresponding work will be released.  All merged PRs should be associated with a milestone, and all issues resolved by a merged PR or a commit should have a milestone.  Milestones are named by the full semver version of the release, e.g. `2.1.0`, `0.1.1`, `9.0.0`.  When the version is published, that milestone should be closed.  There should never be zero open milestones for a given module: when one milestone is closed, a new one is created for the next patch version.  For example, once `2.1.0` is released then the milestone for that version will be closed and a new milestone for `2.1.1` will be created.++#### Release Notes+It is encouraged to write-up an issue with release notes for major changes, especially for modules that are intended to be used externally to the organization (e.g. hapi, bell, nes) versus hapi core (e.g. pez, topo, shot).  The [hapijs/hapi](https://github.com/hapijs/hapi) repository should have release notes for every major version of the framework.  [This](https://github.com/hapijs/hapi/issues/4017) is a great example of typical release note format and ideal level of detail.
It is encouraged to create an issue with release notes for major changes, especially for modules that are intended to be used externally to the organization (e.g. hapi, bell, nes) versus hapi core (e.g. pez, topo, shot).  The [hapijs/hapi](https://github.com/hapijs/hapi) repository should have release notes for every major version of the framework.  [This](https://github.com/hapijs/hapi/issues/4017) is a great example of typical release note format and ideal level of detail.
devinivy

comment created time in 2 days

Pull request review commenthapijs/.github

Add initial documentation on issue, PR, and release maintenance

+# Maintenance+This document outlines basic procedures for maintenance of issues, PRs, and releases.++## Issues and Pull Requests+Issues and pull requests are at the core of hapi's approach to documentation and messaging to the broader community.  They are rigorously labeled, associated with releases, and assigned to collaborators responsible for their resolution.  Official discussions, release notes, announcements, and community support all generally take the form of issues.  Finally, the source of truth for our changelogs are also managed through issues.++### Labels+Labels are standardized through [organization defaults](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-default-labels-for-repositories-in-your-organization).  Here are some notable ones:+ - `support` - requests for clarification or help.+ - `bug` - reports of unintended behavior.+ - `security` - indication of security implications.+ - `feature` - requests for new functionality.+ - `release notes` - documentation of changes in major releases, sometimes accompanied by a migration guide.+ - `documentation` - non-code related changes to the readme, API docs, or similar.+ - `dependency` - changes to underlying or peer dependencies.

I'd just leave out the "underlying or peer" part.

devinivy

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent
more