profile
viewpoint
Seth Holladay sholladay @noirdoor Boston, MA https://seth-holladay.com A human seeking a full stack of pancakes and software, bug free.

sholladay/envy 15

Load .env files and environment variables

sholladay/app-ready 8

Support graceful start in your app

sholladay/await-url 4

Wait for a given URL to continue

sholladay/build-dir 3

Get a place to put your build

sholladay/dangit 3

A utility library for JavaScript quirks.

sholladay/create-deno 2

Set up your Deno projects

sholladay/delivr 2

Build your code and ship it to S3

sholladay/branch-name 1

Get the current branch name

sholladay/build-files 1

Read the files from your build

sholladay/code-dir 1

Find the parent directory for top level projects.

issue commentsholladay/fundraising-for-hapi

Premium modules

I think there should be two options:

  • A one time payment for individual modules (maybe $40-$50)
  • A subscription that includes all modules, including future modules (maybe $200-$300 per year)
sholladay

comment created time in 3 hours

issue commenttypicode/husky

Husky hooks skipped

It is probably time for a community fork that is based on v3, or that at least uses run-node.

Alex0007

comment created time in a day

issue commentsholladay/pogo

Automatic body parsing

Sure, well the first thing to do would be to write a test like the request tests that we have already. When we use server.inject() in those tests, we are basically making a fake ServerRequest object and giving it to the Pogo server as if it were a real HTTP request. You would do the same when making a test for request.payload.

The tests should check at least two cases:

  • When the Content-Type header is application/json, then request.payload must be a parsed JSON object
  • When the Content-Type header is any other value, then request.payload is a stream, same as request.body.

In the tests, you would pass an object to server.inject() that has a body property that conforms to the Deno.Reader interface (because that's how the body of the ServerRequest class works). An example of something like that is a StringReader. Should like roughly like this...

const response = await server.inject({
    body : new StringReader(JSON.stringify({ foo : 'bar' }))
    // ...
});

After the tests are written, then the next step would be to add the automatic body parsing to the framework. I haven't thought too much about the architecture, but it would happen somewhere around this part of the code where we create our request object: https://github.com/sholladay/pogo/blob/5a72c718b8aca97733540cc8ba13085eb69db020/lib/server.ts#L50-L54

It would be good to look into how hapi does this internally.

yereby

comment created time in a day

pull request commentsindresorhus/ky

Fix TypeError on Edge 18

I prefer the approach in #261 because it should handle .extend() properly. But whatever works. If you are able to write a test, we can just update the code in this PR.

belgattitude

comment created time in 2 days

issue commentsholladay/pogo

Accessing request payload

Not yet, I just haven't gotten around to adding automatic body parsing. It should be pretty easy to do though, if you'd like to make a PR.

yereby

comment created time in 2 days

push eventsholladay/pogo

Jérémy

commit sha 5a72c718b8aca97733540cc8ba13085eb69db020

Update README.md (#40)

view details

push time in 2 days

PR merged sholladay/pogo

Update README.md

We have to pass run argument to deno command now to run a script

+1 -1

0 comment

1 changed file

yereby

pr closed time in 2 days

issue commentsindresorhus/ky

How to catch a TimeoutError ? And how to get information about URL which has timed out ?

You are attempting to use try / catch on a Promise, but promises don't throw, they reject, which is different.

You have two options:

  1. Use .catch(() => { /* ... */ }) instead of catch (error) { /* ... */ }
  2. Use await to "unwrap" thr promise.

Here's an example of the latter:

try {
    return await api.get('foobar', { timeout: 1 }).json();
} catch(e) {
    console.log('Error', e); // Never caught
}

As for reporting the URL of the timed out request, that seems like a reasonable thing to add. I'm not sure if the URL was intentionally omitted or not. We'll need to consider the implications of including potentially untrusted data in our error messages, but I think it should be fine.

ByScripts

comment created time in 3 days

issue openedhapijs/inert

Directory listings faill with a 500 when path is absolute

<!-- ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ You must complete this entire issue template to receive support. You MUST NOT remove, change, or replace the template with your own format. A missing or incomplete report will cause your issue to be closed without comment. Please respect the time and experience that went into this template. It is here for a reason. Thank you! ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ -->

Support plan

<!-- We are here to help!

You do not need to pay to receive support. Free community based support is, by its nature, limited to available community members able to help. Most community support issues are resolved within 2 weeks.

Before submitting an issue, please review the various support plans available at https://hapi.dev/support/. That page includes useful information about faster and free channels to ask questions, as well as priority support options to meet you needs. -->

  • which support plan is this issue covered by? (e.g. Community, Core, Plus, or Enterprise): Community
  • is this issue currently blocking your project? (yes/no): No
  • is this issue affecting a production system? (yes/no): No

Context

  • node version: 14.1.0
  • module version with issue: 5.1.3 through 6.0.1
  • last module version without issue: 5.1.2
  • environment (e.g. node, browser, native): Node
  • used with (e.g. hapi application, another framework, standalone, ...): hapi
  • any other relevant information: I believe this regression was caused by https://github.com/hapijs/inert/commit/4514a5e367aeb03be94fc04294c5b30e509eebef

What are you trying to achieve or the steps to reproduce?

<!-- Describe your issue in detail, including full steps to reproduce the issue, any configuration, schemas, code samples, or inputs needed. Make sure to wrap all code examples in backticks so that they display correctly. Before submitting an issue, make sure to click on the Preview tab above to verify everything is formatted correctly. -->

Trying to serve a directory based on an absolute path, as shown in the example below. Using the example, visiting / in the browser fails to render the directory listing. Visiting a subpath that is a file does work, such as /app.js. However, subpaths that are directories also fail to render their directory listing.

In the example, removing path.resolve() "fixes" the issue. Please note that, in my real app, I have path set to a function and the actual value is determined by some business logic that walks the filesystem and returns an absolute path.

'use strict';

const path = require('path');
const hapi = require('@hapi/hapi');
const inert = require('@hapi/inert');

const server = hapi.server({
    debug : {
        log     : ['error'],
        request : ['error']
    },
    port : 3000
});

const start = async () => {
    await server.register([inert]);

    server.route({
        method : 'GET',
        path   : '/{filepath*}',
        handler : {
            directory : {
                path            : path.resolve('build'),
                redirectToSlash : true,
                listing         : true
            }
        }
    });

    await server.start();
};

start();

What was the result you got?

A 500 Internal Server Error, which seems to be caused by inert joining an absolute path with another absolute path, resulting in a path that does not exist. For some reason, this doesn't happen on subpaths that are files.

What result did you expect?

The directory listing should be shown.

created time in 3 days

pull request commentsindresorhus/np

Ensure GitHub status checks have passed

How would retrying up to one minute when there are no branch protection rules motivate people to enable them?

It's about reliability. Take Sindre, for example. As you mentioned, he doesn't currently use branch protection. With the algorithm I proposed, it'll still work for his repos as-is, but if there's an unusually high delay, as happens occasionally (on bad days I've seen it take a couple of minutes to create the status), then np would more eagerly skip this step compared to if he enabled branch protection. The docs can mention this as a means to improve reliability.

Additionally, I suspect that a lot of people may just not be aware of the branch protection feature and its ability to guarantee a status check has passed. It's not exactly front and center in the GitHub UI. There are good reasons to enable it that have nothing to do with np, so mentioning it in the docs would be a good thing for the community.

People who don’t use status checks couldn’t enable protection and therefore would always have to wait a whole minute.

No, not always. I'm not proposing a one minute delay. It's a timeout. It's only a whole minute in the worst case.

sonicdoe

comment created time in 3 days

pull request commentsindresorhus/ky

Fix TypeError on Edge 18

The constructor is not the only place that we use mergeHeaders(), though, and thus it is not the only place that is prone to the error. I believe your approach would fail when undefined headers are received via ky.extend().

It's for precisely these kinds of reasons that we cannot accept this without a test. I disagree that it's hard to test. You should be able to make a test that overrides the Headers constructor to match the offending browsers.

belgattitude

comment created time in 4 days

issue commentsindresorhus/ky

Question regarding Q&A

Add a ci/cd workflow based on github actions (rather than travis)

Why? Personally, I like Travis. The config is simpler, among other reasons.

npx es-check es6 ./umd.js to ensure code is valid es6

I don't think this is quite what we want. The intention with the UMD build is simply to change the module format, not the target ES version. Which is to say, umd.js is not ES6. It's meant to work in "the latest version of Chrome, Firefox, and Safari" and Node.js, as per the documentation. In practical terms, that basically means you should treat it as ES Next, regardless of what ES features we currently happen to use (e.g. we could start using the nullish coalescing operator). What I think we should do, though, is add a umd.es5.js file, aka #255. That way, you can easily use Ky in older browsers. So we'll have ES Next and ES5.

[Build] Experiment rollup - babel with a browserlist config (I know that you're supporting modern browsers). We can plug this into rollup or use microbundle/tsdx as well and provide multiple exports (modern...).

I'm not necessarily against this, but IMO it wouldn't change much for the codebase, yet it would introduce complex tooling. It's pretty easy to just check the compatibility table on MDN / caniuse.com and only use features that already have broad support. There hasn't been anything I can think of where we've really needed Babel. A few years ago, this would have made a lot of sense. But these days, the spec moves incrementally and the browser vendors are doing a reasonable job keeping up.

belgattitude

comment created time in 4 days

pull request commentdenoland/deno

Fixing error TS2345

Those are really two changes and they can be separated:

  • Updating fromFileUrl() so it does new URL(url.toString()).pathname can be done in a patch release, as it is not a breaking change
  • Updating the URL type definition to match TypeScript's is a breaking change since it removes one type of allowed input. There's an argument to be made that this shouldn't be released until Deno 2.0.0. I don't know what the semver policy here is regarding type definitions. Bumping the major for such a small thing is annoying, but IMO that's the only way to truly respect the purpose of semver.
Bidek56

comment created time in 4 days

pull request commentsindresorhus/ky

Default to empty object instead of undefined for headers param

@belgattitude the best way to help would be to write a test that fails on the master branch but passes with the changes in this PR. If no one gets around to it, I plan to take care of it sometime this week. But that would definitely speed things up. We can get this released quickly once there is a test.

JosNun

comment created time in 4 days

Pull request review commentsindresorhus/ky

Default to empty object instead of undefined for headers param

 const supportsStreams = typeof globals.ReadableStream === 'function'; const supportsFormData = typeof globals.FormData === 'function';  const mergeHeaders = (source1, source2) => {-	const result = new globals.Headers(source1);+	const result = new globals.Headers(source1 || {}); 	const isHeadersInstance = source2 instanceof globals.Headers;-	const source = new globals.Headers(source2);+	const source = new globals.Headers(source2 || {});  	for (const [key, value] of source) {-		if ((isHeadersInstance && value === 'undefined') || value === undefined) {+		if ((isHeadersInstance && (value === undefined || value === 'undefined')) {

Thank you. Fixed.

JosNun

comment created time in 4 days

push eventJosNun/ky

Seth Holladay

commit sha ed657560ec471898e8f75c1abc8739751d3d807d

Fix syntax error

view details

push time in 4 days

issue commentdenoland/deno

React HTMLInputElement

@Bidek56 The problem you are experiencing in your last example is due to the fact that that TypeScript's dom lib only accepts string for the first argument: https://github.com/microsoft/TypeScript/blob/df5981319fc9686dec63305142f7a549e2e6b888/lib/lib.dom.d.ts#L15952

Deno's type definition allows string | URL for the first argument (and that's what fromFileUrl() passes to it): https://github.com/denoland/deno/blob/7858ebd493afe15b4b583b0218c27e166572b280/cli/js/lib.deno.shared_globals.d.ts#L1240

I'm not sure if there's a way to resolve the conflict. I would expect there to be some way to make Deno's type defs take precedence. But even if there is, that may cause other issues.

In this particular case, a simple fix could be to open a PR to change fromFileUrl() to something like this:

function fromFileUrl(url: string | URL): string {
  return new URL('', url).pathname;
}
Bidek56

comment created time in 4 days

pull request commentsindresorhus/np

Ensure GitHub status checks have passed

That's why retries are so important. It doesn't currently retry when totalCount is 0, but it should. My suggestion is to retry up to one minute when there are no branch protection rules.

I do think that more people would enable branch protection if np gave them a good reason to do so.

sonicdoe

comment created time in 5 days

push eventsholladay/pogo

Seth Holladay

commit sha ed8481152ebde935baae7e4e54dee2180640ada8

Update documentation

view details

push time in 5 days

push eventJosNun/ky

Seth Holladay

commit sha 2373c1b86ff15006e306ee0dee5537379c9a1a4b

Handle all falsey inputs for merging headers

view details

push time in 5 days

issue commentsholladay/pogo

Serve a directory of static files

h.file() was merged and is now tested, documented, and fully supported. I think we're ready for someone to work on pogo.directory(). Should be relatively straightforward. Any takers?

nalaka

comment created time in 5 days

push eventsholladay/pogo

Seth Holladay

commit sha b7b891129e617c6cac8a3fb576439c144e3794cd

Document h.file()

view details

push time in 5 days

issue commentdenoland/deno

std/http: Allow using getCookies() without ServerRequest

Yeah, this frustrated me, too. I ended up using as any in Pogo to work around it.

https://github.com/sholladay/pogo/blob/2af2f39e0294ff186156a810247b353a10d4962d/lib/request.ts#L32

jakajancar

comment created time in 5 days

pull request commentsindresorhus/np

Ensure GitHub status checks have passed

If I understand the code correctly, it currently delays 10 seconds, then tries to check the status, and if totalCount happens to be zero at that time, it gives up and skips, without retrying. That seems pretty fragile.

Here's how I would approach this:

  1. Delay ten seconds
  2. Predict whether a status check is likely to eventually exist, by:
    • Fetching status checks of recently pushed commits on the remote prior to those pushed by np (as @sonicdoe mentioned), but also...
    • Fetching the branch protection rules using one of these APIs:
      • https://developer.github.com/v3/repos/branches/#get-branch-protection
      • https://developer.github.com/v3/repos/branches/#get-status-checks-protection
      • https://developer.github.com/v3/repos/branches/#get-all-status-check-contexts
  3. Check the commit status and if totalCount === 0, then:
    • If step 2 found previous status checks / branch protection contexts, retry every ten seconds, up to a limit of five minutes
    • If step 2 errored or found no status checks / branch protection contexts, retry every ten seconds, up to a limit of one minute
sonicdoe

comment created time in 5 days

issue commentsindresorhus/ky

Compatibility with chrome 53

Chrome 53 is four years old. How has it not been updated? 😄

Airkro

comment created time in 5 days

issue closedsindresorhus/ky

Compatibility with chrome 53

Something wrong with this line:

https://github.com/sindresorhus/ky/blob/master/index.js#L52

I have to do this to make it work:

  const mergeHeaders = (source1, source2) => {
-   const result = new globals.Headers(source1);
+   const result = source1 ? new globals.Headers(source1) : new globals.Headers();

closed time in 5 days

Airkro

issue commentsindresorhus/ky

Compatibility with chrome 53

Duplicate of #250

Airkro

comment created time in 5 days

issue commentsindresorhus/ky

`error.response.clone()` trigger error

Duplicate of #251

Airkro

comment created time in 5 days

issue closedsindresorhus/ky

`error.response.clone()` trigger error

https://github.com/sindresorhus/ky/blob/master/index.js#L398

Sometimes error.response return null.

I have to do this to make it work:

- response: error.response.clone(),
+ response: error.response ? error.response.clone() : null,

closed time in 5 days

Airkro

issue commentxojs/eslint-config-xo-react

Include accessibility rules

Perhaps it is possible to work around this by trying to require eslint-plugin-jsx-a11y and silently skipping its rules if it is not found, instead of crashing?

I'd rather it be required. But if it had to be optional, a warning should still be printed to avoid silent accidental failure.

Regardless, my understanding is that configs cannot directly import plugins. So I don't think it's even possible to make it optional.

sholladay

comment created time in 6 days

push eventvenikman/pogo

Seth Holladay

commit sha 933c77b22cd23b59a3b8c737327205ac80faac6c

Add sponsor button

view details

Seth Holladay

commit sha 2af2f39e0294ff186156a810247b353a10d4962d

Add confine option for h.file() (#38) Defaults to the current working directory.

view details

Seth Holladay

commit sha 3f2f2f411b24fda4190efdcdcc359d3760b01f1f

Merge branch 'master' into master

view details

push time in 7 days

push eventsholladay/pogo

Seth Holladay

commit sha 2af2f39e0294ff186156a810247b353a10d4962d

Add confine option for h.file() (#38) Defaults to the current working directory.

view details

push time in 7 days

delete branch sholladay/pogo

delete branch : file-confine

delete time in 7 days

PR merged sholladay/pogo

Add confine option for h.file()

Defaults to the current working directory.

+71 -2

0 comment

5 changed files

sholladay

pr closed time in 7 days

push eventsholladay/pogo

Seth Holladay

commit sha 54f92d71f10e441a67314c866da42e9ff3adc3d4

Use explicit type definitions for React Also update to React 16.13.1 Fixes #35

view details

Seth Holladay

commit sha de4465a97e45f126e0bb47658b43073fb69f9e13

Use Deno v1.1.1 in CI

view details

Seth Holladay

commit sha 6bf67cf8c335c8bb91836f9549f4e4dc7ad33571

Update example tests

view details

Seth Holladay

commit sha 933c77b22cd23b59a3b8c737327205ac80faac6c

Add sponsor button

view details

Seth Holladay

commit sha 229d257e44c55483169c29916ce4375b930a11c3

Merge branch 'master' into file-confine

view details

push time in 7 days

push eventsholladay/pogo

Seth Holladay

commit sha 75aa5b3c7c7264d2bf9c86cf81eec9997893be59

Add confine option for h.file() Defaults to the current working directory.

view details

push time in 7 days

PR opened sholladay/pogo

Add confine option for h.file()

Defaults to the current working directory.

+70 -1

0 comment

4 changed files

pr created time in 7 days

create barnchsholladay/pogo

branch : file-confine

created branch time in 7 days

pull request commentsindresorhus/is-path-inside

Fix handling of root directory as parentPath

Would you be able to add some more tests maybe?

Sure, what did you have in mind? Did you see the assertions I added in the first commit, https://github.com/sindresorhus/is-path-inside/pull/15/commits/bde790ba081d36751d5b8332ec1b2481fc650dfd? I tried to add all of the relevant permutations I could think of for this module.

sholladay

comment created time in 7 days

push eventsholladay/is-path-inside

Seth Holladay

commit sha 11b6aaae5f899e943365e7d825713e615d492897

Use template string Co-authored-by: Sindre Sorhus <sindresorhus@gmail.com>

view details

push time in 7 days

Pull request review commentsindresorhus/is-path-inside

Fix handling of root directory as parentPath

 const path = require('path');  module.exports = (childPath, parentPath) => {-	childPath = path.resolve(childPath);-	parentPath = path.resolve(parentPath);--	if (process.platform === 'win32') {-		childPath = childPath.toLowerCase();-		parentPath = parentPath.toLowerCase();-	}--	if (childPath === parentPath) {-		return false;-	}--	parentPath += parentPath.endsWith(path.sep) ? '' : path.sep;--	return childPath.startsWith(parentPath);+	const relation = path.relative(parentPath, childPath);+	return Boolean(+		relation &&+		relation !== '..' &&+		!relation.startsWith('..' + path.sep) &&

Done. 👍

Would be nice to codify that in XO. I find ${} somewhat less readable than <code> + </code>, so I have a habit of only using template strings if it actually shortens the code, which it does in some cases, but not here.

sholladay

comment created time in 7 days

push eventsholladay/is-path-inside

Seth Holladay

commit sha b2bc9ea6c888aeb1fa913bb66aab9baf5a94e46f

Simplify by using path.relative()

view details

push time in 8 days

PR opened sindresorhus/is-path-inside

Fix handling of root directory as parentPath

Fixes #14

Before this PR:

isPathInside('/foo', '/');  // false

After this PR:

isPathInside('/foo', '/');  // true
+94 -22

0 comment

2 changed files

pr created time in 8 days

issue openedsindresorhus/is-path-inside

False negative when parent path is the root directory

The code inside of this module assumes that path.resolve(parentPath) returns a path without a trailing slash, which is generally correct. However, the root directory is an exception that is not currently accounted for.

This results in a false negative:

isPathInside('/foo', '/');  // false

created time in 8 days

push eventsholladay/is-path-inside

Seth Holladay

commit sha bde790ba081d36751d5b8332ec1b2481fc650dfd

Fix handling of root directory as parentPath

view details

push time in 8 days

fork sholladay/is-path-inside

Check if a path is inside another path

fork in 8 days

issue openedsholladay/fundraising-for-hapi

Premium modules

This idea is to have a collection of modules which are pay-to-use. Generally, a premium module would be defined as such based on it being needed for production readiness and the scale of applications that need it being relatively large.

For example, API rate-limiting is a common need for public, production applications that are also popular or at-risk for abuse. However, many apps do not need API rate-limiting, such as those that are for internal use only, or those that are still in development, or some that use hapi for rendering websites without an API, etc. This makes rate-limiting a good candidate for a premium module, as its use case is fairly specific and anyone who needs it is likely making money in the course of using it.

Some other candidates:

  • Server-side caching (catbox) - only needed to improve performance once responses become computationally expensive and client-side caching is not enough, which typically implies a large-scale usage
  • Telementry / metrics - mostly used for monitoring production operations
  • OAuth - used for login/signup via external systems, which is only applicable to some apps, and is often used to improve security or for the convenience of not managing an in-house database
  • Role-based access control - used for relatively complex apps that have multiple types of users, which often implies a source of revenue or business use
  • Integrations with 3rd party products and SaaS tools (e.g. Datadog, HashiCorp Vault, etc.) - mostly used to enhance production monitoring, deployment, and security

Thanks to @aalimovs for mentioning this in Slack.

created time in 9 days

push eventsholladay/pogo

Seth Holladay

commit sha 933c77b22cd23b59a3b8c737327205ac80faac6c

Add sponsor button

view details

push time in 10 days

issue closedsholladay/pogo

Allow React support to be optional

It would be nice if React support was optional, such that if you didn't want to use it, the dependencies aren't downloaded. Currently, the entire React library is imported whether or not you want to use it, which might not be ideal for something like a pure API.

It could be done by allowing React to be added in manually by importing something like react.ts (which would be next to main.ts) and using its exports, or by allowing React to be imported by the consumer and then provided to the API (this would allow users to select a specific version of React as well, or maybe even be able to use Preact).

I'm not sure on the best way to implement it, but if this is something worth looking into, I'd be happy to try and write up a PR!

closed time in 10 days

luvies

issue commentsholladay/pogo

Allow React support to be optional

Having thought about this for a few days, here's what I've decided:

  1. React support will remain built-in. It's a selling point and I personally use it a lot. Deno renders JSX out-of-the-box, and most backend projects will need a view engine of some sort, so we might as well leverage it.
  2. The user ought to have some control over the React version used by the framework, somewhat akin to Node's peerDependencies. For that, I will accept a PR that adds a react server option, which can be used to override the built-in version that ships with the framework. However, I would encourage users to use an import map instead, so that only one React is ever downloaded. PR welcome for documenting how to do that.

I'm happy to revisit this approach in the future. In particular, if Deno's tooling around peer dependencies improves, that may open up new opportunities for us.

luvies

comment created time in 10 days

create barnchsholladay/fundraising-for-hapi

branch : master

created branch time in 10 days

created repositorysholladay/fundraising-for-hapi

Working group raising money for the hapi.js web server framework

created time in 10 days

push eventsholladay/pogo

Seth Holladay

commit sha de4465a97e45f126e0bb47658b43073fb69f9e13

Use Deno v1.1.1 in CI

view details

Seth Holladay

commit sha 6bf67cf8c335c8bb91836f9549f4e4dc7ad33571

Update example tests

view details

push time in 10 days

issue commentsholladay/pogo

Error when running example

@bdearborn Good news! I was finally able to reproduce your error and I was able to work around it with commit https://github.com/sholladay/pogo/commit/54f92d71f10e441a67314c866da42e9ff3adc3d4.

I still think the error when using Pika is probably an issue with Deno itself, as Deno seems to be interpreting the .d.ts file delivered by Pika as a TypeScript source code file rather than a type definition file. But for now, using jspm.dev and loading the type definitions manually using @deno-types works.

Could you try the example again and let me know how it goes? You may need to use the --reload flag. I hope it works for you! 🤞

bdearborn

comment created time in 10 days

push eventsholladay/pogo

Seth Holladay

commit sha 54f92d71f10e441a67314c866da42e9ff3adc3d4

Use explicit type definitions for React Also update to React 16.13.1 Fixes #35

view details

push time in 10 days

issue closedsholladay/pogo

Error when running example

Running the first example on deno results in an error.

import pogo from 'https://deno.land/x/pogo/main.ts';

const server = pogo.server({ port : 3000 });

server.router.get('/', () => {
    return 'Hello, world!';
});

server.start();

deno run --unstable --allow-read=\ --allow-write=\ --allow-net .\server.js error: 'implements', 'interface', 'let', 'package', 'private', 'protected', 'public', 'static', or 'yield' cannot be used as an identifier in strict mode at https://cdn.pika.dev/-/csstype@v2.6.10-9lGFwmNeuxj9xXremWKA/dist=es2019,mode=exports/index.d.ts:1:7,Expected Comma, got Some(Word(StandardLonghandProperties)) at https://cdn.pika.dev/-/csstype@v2.6.10-9lGFwmNeuxj9xXremWKA/dist=es2019,mode=exports/index.d.ts:1:17

closed time in 10 days

bdearborn

issue commentsholladay/pogo

Error when running example

This is definitely an upstream bug. Probably a bug in Deno itself (see https://github.com/denoland/deno/issues/6448), but possibly in the Pika CDN. My recommendation is to try downgrading Deno to an earlier version and see if that works, using a command like deno upgrade --version 1.0.2. I'm not sure what the best version to use is at the moment but our CI tests passed using Deno 1.0.2.

bdearborn

comment created time in 10 days

issue commentdenoland/deno

identifier in strict mode

A Pogo user reported this same problem in https://github.com/sholladay/pogo/issues/35. I haven't been able to reproduce it yet, but they are using Deno 1.1.1 on Windows 10.

Bidek56

comment created time in 10 days

issue commentsholladay/pogo

pre property in server.routes

I would accept a high quality PR for hapi's pre feature. That said, I've never needed or used it myself, so I personally have no plans to work on it anytime soon. Instead, I just call the "pre" methods directly in the handler itself, which is more explicit and about the same amount of code, sometimes even fewer lines because there's no need for an array.

sojohnnysaid

comment created time in 10 days

starteddigitallyinduced/ihp

started time in 12 days

issue commentsholladay/pogo

Error when running example

What version of Deno are you on? I cannot reproduce this.

bdearborn

comment created time in 12 days

pull request commentsindresorhus/ky

Default to empty object instead of undefined for headers param

We'll need a test for this, otherwise we'll undoubtedly break it by accident in the future. Might want to hold off on that until Sindre chimes in, though. I'm personally fine with this if it's such a small change. The test would need to override the Headers class to match the behavior of Edge.

JosNun

comment created time in 14 days

push eventsholladay/seth-holladay.com

Seth Holladay

commit sha f0a7d7e25aa18b529aeca6fe60987e26abd757e9

Update the FAQ page

view details

push time in 15 days

push eventsholladay/seth-holladay.com

Seth Holladay

commit sha cb17519dca514c0d99aad3453239aecc04c809d8

Update the Donate page

view details

push time in 15 days

push eventsholladay/seth-holladay.com

Seth Holladay

commit sha 8191071050836c3d8a936c29b1cf0be784c0ce18

Update the About page

view details

push time in 16 days

issue commentsindresorhus/ky

Edge <= 18 Invalid argument exception

Does it work if you pass null? Personally, I'm fine with adding a simple ternary. But yeah, earlier versions of Edge may have other problems too, as they are unsupported.

JosNun

comment created time in 16 days

issue closedsindresorhus/ky

not get corrrect html

I hope that help me I try to get html from this Link :https://www.t13.cl/noticia/tendencias/series-netflix-distopicas-maratonear-26-05-2020

I got the different html when use got and Edge. Don't paste the whole header, I would have to define a user-agent?

with got I obtain:

<head>
 <title>T13 | Tele 13</title>
</head>

<head> <title>6 series (Netflix, Amazon) por si el mundo no vuelve a ser igual | Tele 13 </title> </head>




 with **browser edge** I obtain:

<head> <title>6 series (Netflix, Amazon) por si el mundo no vuelve a ser igual | Tele 13 </title> </head>

I want to read metadata!
Regards!!

closed time in 17 days

dverdugo85

issue commentsindresorhus/ky

not get corrrect html

Closing due to lack of response. Happy to re-open if new info comes along.

dverdugo85

comment created time in 17 days

issue closeddenoland/deno

Unclear error message when upgrading to non-existent version

I was trying to figure out which version of Deno broke my app, so I was bisecting different versions blindly and discovered an amusing error. When deno upgrade is given a non-existent version, its output is unclear and contradictory, as it says that the version was found, but then fails to download it due to a 404 Not Found error.

Is "Version has been found" hardcoded? 😄

❯ deno upgrade --version 1.0.6
Version has been found
Deno is upgrading to version 1.0.6
downloading https://github.com/denoland/deno/releases/download/v1.0.6/deno-x86_64-apple-darwin.zip
error: Import 'https://github.com/denoland/deno/releases/download/v1.0.6/deno-x86_64-apple-darwin.zip' failed: 404 Not Found

closed time in 17 days

sholladay

issue openeddenoland/deno

Unclear error message when upgrading to non-existent version

I was trying to figure out which version of Deno broke my app, so I was bisecting different versions blindly and discovered an amusing error. When deno upgrade is given a non-existent version, its output is unclear and contradictory, as it says that the version was found, but then fails to download it due to a 404 Not Found error.

Is "Version has been found" hardcoded? 😄

❯ deno upgrade --version 1.0.6
Version has been found
Deno is upgrading to version 1.0.6
downloading https://github.com/denoland/deno/releases/download/v1.0.6/deno-x86_64-apple-darwin.zip
error: Import 'https://github.com/denoland/deno/releases/download/v1.0.6/deno-x86_64-apple-darwin.zip' failed: 404 Not Found

created time in 17 days

startedlocaltunnel/localtunnel

started time in 18 days

issue commentsholladay/pogo

Middleware/ext support

I believe I understand. In your Server interface, new means passing the class itself, right?

Can you show a usage example with your proposed API to clarify how it would work from the user's perspective? It's like this, right?

class Middleware {
    constructor(h) {
        this.foo = 'could measure time here'
    }
    onPreStart() {}
    onPostStart() {}
    // ...
}

pogo.server({
    ext(Middleware)
});

The above is a little too object-oriented for my liking. But I think I see the appeal.

The way that hapi lets you keep track of state like timings is with server.app and request.app. It's just a namespace whose value is an empty object and you can assign whatever you want to it. Kind of makes sense to attach request-level state to the request instance itself, for example. It can be a little tricky to debug, though, since it's not obvious where the state came from.

luvies

comment created time in 20 days

issue commentsholladay/pogo

Allow React support to be optional

The reason for aliasing server.ext() would be to make it easier to port hapi applications to Pogo. I realize that's kind of a niche case. At the moment, I've managed to maintain API compatibility for everything I've added without any real complexity. It's not crucial to keep doing that, but I do have a lot of Node.js/hapi apps I would like to port to Deno/Pogo over time and I think it would help encourage people to adopt Deno.

luvies

comment created time in 20 days

issue commentsholladay/pogo

Allow React support to be optional

I've had a look at how hapi implements ext and the internals are very complicated, so I think I'll try to go for something a little more simple for the implementation

Yeah, most of hapi's internals are relatively simple and beautiful (e.g. the Response class or the bounce module), but the event system and extension points are a little wonky by comparison. The fact that server.ext() and server.on() are different APIs is slightly weird to me, for example. It's probably because extension points like onPreResponse can return a value whereas handlers for other types of events are not supposed to. But I don't really like it, conceptually they are all just events. I imagine we can simplify this in Pogo by implementing server.on() first and then - if it's even necessary - maybe server.ext() can just be an alias or shortcut akin to how server.router.get() is just a shortcut. We also don't need to implement hapi's advanced event handling features, I've never needed them.

I thought about this because I wanted to look into writing my own MVC-like framework (similar to Nest.js I think, but I like simple and explicit so not identical) and use pogo as the underlying server. Making React optional then came from the fact that nearly all the servers I have written/will write are pure APIs with SPA fronts, meaning React really shouldn't be included if it doesn't need to be.

That's great! I haven't tried Nest.js, but I've used Next.js and the thing I like about it is that it encourages server-side rendering, which is important for the health of the web. I feel that SPAs have caused a lot of accidental harm in terms of usability and reliability, SEO, etc. People will do whatever is convenient, so I want to make it easy for people to fix those problems with server-side rendering. To do it like Next.js does, you'd probably want to use a combo of ReactDOMServer.renderToStaticMarkup() for the page and ReactDOMServer.renderToString() for the app container element (relevant code in Next.js is here). If you render it yourself that way, it will bypass Pogo's usage of React, but Pogo will still send it as HTML.

luvies

comment created time in 21 days

issue commentsholladay/pogo

Allow React support to be optional

I've had a look at how hapi implements ext and the internals are very complicated, so I think I'll try to go for something a little more simple for the implementation

Yeah, most of hapi's internals are relatively simple and beautiful (e.g. the Response class or the bounce module), but the event system and extension points are a little wonky by comparison. The fact that server.ext() and server.on() are different APIs is slightly weird to me, for example. It's probably because extension points like onPreResponse can return a value whereas handlers for other types of events are not supposed to. But I don't really like it, conceptually they are all just events. I imagine we can simplify this in Pogo by implementing server.on() first and then - if it's even necessary - maybe server.ext() can just be an alias or shortcut akin to how server.router.get() is just a shortcut. We also don't need to implement hapi's advanced event handling features, I've never needed them.

luvies

comment created time in 21 days

issue openedSoremwar/deno_types

Compile errors when using types for ReactDOMServer

To reproduce, save the following code to a file named main.tsx:

import React from 'https://cdn.pika.dev/react@16.13.1';
// @deno-types="https://deno.land/x/types/react-dom/v16.13.1/server.d.ts"
import ReactDOMServer from 'https://dev.jspm.io/react-dom@16.13.1/server';

console.log(React.isValidElement(null));
console.log(ReactDOMServer.renderToStaticMarkup(<h1>Hello, World</h1>));

Now run:

deno run main.ts

Expected output

false
<h1>Hello, World</h1>

Actual output

Tons of errors, such as...

TS2717 [ERROR]: Subsequent property declarations must have the same type.  Property 'view' must be of type 'SVGProps<SVGViewElement>', but here has type 'SVGProps<SVGViewElement>'.
      view: React.SVGProps<SVGViewElement>;
      ~~~~
    at https://deno.land/x/types/react/v16.13.1/react.d.ts:3835:7

    'view' was also declared here.
                view: React.SVGProps<SVGViewElement>;
                ~~~~
        at https://cdn.pika.dev/-/react@v16.13.1-ByypZEPVPs6cpkpGdpQK/dist=es2019,mode=types/index.d.ts:3098:13

Found 177 errors.

Environment

macOS 10.14.6

❯ deno --version
deno 1.1.0
v8 8.4.300
typescript 3.9.2

created time in 21 days

delete branch sholladay/pogo

delete branch : static-files

delete time in 21 days

push eventsholladay/pogo

Seth Holladay

commit sha 2ab847c796e25ffdafd5c0026f46e0b057738a39

Add h.file() for serving static files (#32) * Add h.file() for serving static files * Fix request.params value for wildcard param * Use Pika CDN to get TypeScript types for React Unfortunately, Pika does not yet have the ability to load ReactDOMServer, so that is still loaded from JSPM. * Add read access to tests for h.file()

view details

push time in 21 days

PR merged sholladay/pogo

Add h.file() for serving static files

This adds support for serving files based on a given path using a new h.file() method.

Apps that use this will need Deno's --allow-read permission.

Relates to #11

+59 -7

0 comment

7 changed files

sholladay

pr closed time in 21 days

issue commentsholladay/pogo

Allow React support to be optional

PR welcome for server.register() and/or server.ext(), just keep in mind that I haven't decided yet whether I want to actually remove React. I really like the simplicity of the current design.

What inspired this issue, if I may ask? Are you working on an API server? Or you just want to use a different view library?

luvies

comment created time in 21 days

push eventsholladay/pogo

Seth Holladay

commit sha d7194cab2bafbce7ae1800b2eda0e2199fb72565

Add read access to tests for h.file()

view details

push time in 21 days

push eventsholladay/pogo

Seth Holladay

commit sha f56395eeb2211aeb26af793a7680707541302048

Fix request.params value for wildcard param

view details

Seth Holladay

commit sha 099064e91447481e0bde26c96a6cee07df8d3202

Use Pika CDN to get TypeScript types for React Unfortunately, Pika does not yet have the ability to load ReactDOMServer, so that is still loaded from JSPM.

view details

push time in 21 days

issue commentsholladay/pogo

Allow React support to be optional

Yep, I've been thinking about how I want to approach middleware / extension points a lot recently and updating serialize() is likely part of that.

Pogo is modeled after hapi, which uses a well-structured request lifecycle with specific extension points that are pretty similar to what you are proposing. (See the docs and this diagram)

Being able to render things in a onPreResponse would be useful and I think that's a reasonable way to approach supporting React externally, if necessary.

luvies

comment created time in 22 days

IssuesEvent

issue closedsholladay/pogo

Allow React support to be optional

It would be nice if React support was optional, such that if you didn't want to use it, the dependencies aren't downloaded. Currently, the entire React library is imported whether or not you want to use it, which might not be ideal for something like a pure API.

It could be done by allowing React to be added in manually by importing something like react.ts (which would be next to main.ts) and using its exports, or by allowing React to be imported by the consumer and then provided to the API (this would allow users to select a specific version of React as well, or maybe even be able to use Preact).

I'm not sure on the best way to implement it, but if this is something worth looking into, I'd be happy to try and write up a PR!

closed time in 22 days

luvies

issue commentsholladay/pogo

Allow React support to be optional

I'm conflicted on this. On the one hand, I get your point that not everyone will need it, and being able to supply your own React/Preact version would be a genuinely nice feature. On the other hand, it does complicate things, and I think most people do need some sort of template engine / view library.

Part of what's great about Deno is that it can compile JSX out of the box, and I leverage this in Pogo to make it trivial to build webpages with React components. You don't have to do anything complicated with them, you can just use plain HTML syntax if you want to.

To be clear, the important bit that Pogo itself uses is ReactDOMServer and its renderToStaticMarkup() function, which is relatively small and simple. Unfortunately, we do download React too, but only to use its isValidElement() function (here); If Deno supported tree shaking, then that wouldn't be a big deal at all because barely anything would get loaded. And if Deno had an equivalent to Node's peerDependencies, then we could use that to leave the version up to the user. Sadly, Deno doesn't have either of those at the moment, so it's not as optimized as I would like.

What we could do would be to make something like server.register(), where you plug in your own React library. But that adds an extra step to do any sort of view templating. Is that worth it? Maybe.

Ultimately, I think it would be nice to build something like Next.js for Deno, probably as a layer built on top of Pogo. When something like that is available, it would give me more incentive to remove React from Pogo's core.

The good news is that, because of how Pogo is designed, you can probably use Preact already. I haven't tried it, but as long as Preact elements pass React.isValidElement() and can be serialized by ReactDOMServer.renderToStaticMarkup(), which I believe they should, then it will absolutely work. And the version of React whose React.createElement() function is called is totally in your hands as the user, as the elements are created in user code, outside of Pogo.

luvies

comment created time in 23 days

issue openeddenoland/deno

std/http throws on large chunked responses

The chunked response handling in std/http seems to be very broken. When you give it a Reader, it's supposed to send a chunked response, but it breaks with only a few megabytes of data.

Below is a script to reproduce this. If image.jpg is very small, it'll work fine. Interestingly, the amount of data that actually gets sent to the client seems to be somewhat erratic. Sometimes I get ~4 megabytes, sometimes I get < 2 megabytes. Maybe backpressure isn't working properly?

import * as http from 'https://deno.land/std@v0.56.0/http/server.ts';

const respond = async (request: http.ServerRequest) => {
    const file = await Deno.open('./image.jpg');
    await request.respond({
        body   : file,  // works if file is very small, but throws an error if it's a bit large (>4MB ???)
        status : 200
    });
    file.close();
};

for await (const request of http.serve({ port : 3000 })) {
    respond(request);
}

created time in 23 days

issue commentsholladay/pogo

Serve a directory of static files

More progress towards this. I have opened PR #32 which adds h.file() to create a response from a filepath. To fully support directories in a convenient way, pogo.directory() could return a route whose handler uses h.file().

nalaka

comment created time in 24 days

PR opened sholladay/pogo

Add h.file() for serving static files

This adds support for serving files based on a given path using a new h.file() method.

Apps that use this will need Deno's --allow-read permission.

Relates to #11

+38 -4

0 comment

4 changed files

pr created time in 24 days

create barnchsholladay/pogo

branch : static-files

created branch time in 24 days

issue commentsholladay/pogo

Create a logo

@mlovelook no worries, whatever time you have available is fine. Much appreciated.

Were you able to find the Discord? I didn't receive a message from you.

Here's the link: https://discord.gg/HVwFv3 (or if that doesn't work, try this one: https://discord.com/channels/684898665143206084)

sholladay

comment created time in 25 days

pull request commentdenoland/deno_website2

Add random_float and random_int to database

Oh, right. I was thinking they would work because they don't import anything, but of course the export syntax matters, too, and those are still CommonJS. Silly me.

Still, Sindre might be willing to accept a PR to change them to use ES6 export syntax.

yg

comment created time in a month

pull request commentdenoland/deno_website2

Add random_float and random_int to database

Sindre's modules already have TS type definitions and are Deno compatible. Why not just add them?

yg

comment created time in a month

created tagsholladay/pogo

tagv0.4.0

Server framework for Deno

created time in a month

release sholladay/pogo

v0.4.0

released time in a month

push eventsholladay/pogo

P. Envall

commit sha da3b44bfef0007b7ce5739eae7121a0c2d14bf56

Add shortcut for using a custom catch-all handler (#17) * Add mechanism for using a custom catch-all handler Implemented as an option to server instantiation. * use existing utility to set http status code * update mechanism of adding the catchAll handler via server options It now internally uses the router catch-all * Simplify route matching logic * Update to std@v0.56.0 * Simplify request configuration * Simplify syntax in code example Co-authored-by: Seth Holladay <me@seth-holladay.com>

view details

push time in a month

PR merged sholladay/pogo

Add shortcut for using a custom catch-all handler

Implemented here as an option to the server instantiation.

    const server = pogo.server({
        catchAll: async (request, h) => {
            return h.response(`My custom response, ${ request.method }`)
                .code(404);
        }
    });

I started to use pogo to create a development server and quickly realized i wanted to create a catch-all handler for missing routes (akin to the wildcard method matching feature). Happy if you will consider this contribution in some way!

Best regards /p

+71 -9

11 comments

8 changed files

npup

pr closed time in a month

pull request commentsholladay/pogo

Add mechanism for using a custom catch-all handler

LGTM. Just did a bit of cleanup. Let me know if anything doesn't seem right.

Thanks, @npup! 🎉

npup

comment created time in a month

push eventnpup/pogo

Seth Holladay

commit sha 21d9db28c1bbc91108dd39da2ace73fc09ab48d4

Simplify syntax in code example

view details

push time in a month

push eventnpup/pogo

Seth Holladay

commit sha 087eea68cc1a9fb58939da3111b6a2b3c02bc6a6

Simplify request configuration

view details

push time in a month

more