'm having trouble with my custom async middleware...It seems to hang on loading the POST request and the logger middleware doesnt print anything related to that request. It also seems to block any app.use() lines after the line that is cuasing it to hang, which causes 404 to not work. I'm not sure what the problem is with my code (im using async/await with bcrypt and mongodb) but it shouldnt block other methods after it? What's weird is that app.get() lines that are BEFORE the problematic line work totally fine. I'll post my code here if needed but I'm not sure what is causing it to hang. I'm pretty sure ive handled all the errors AND changed some of the functions to async functions. I also checked that I'm sending a response with res.json() or res.send() so its not that im not sending anything...

heres my middleware file: https://hastebin.com/ifocicitem.js and heres where i use it: https://hastebin.com/juhovowuvo.coffeescript

Express tests: https://github.com/expressjs/express/blob/master/test/res.jsonp.js

Should be put in __tests__/modules/jsonp.ts

No need to write as many tests as in Express, if it hits 100% coverage, it's enough

Describe the bug

With cache enabled in the browser: Without cache enabled in the browser: Both send a 200 and the data.

To Reproduce

Steps to reproduce the behavior:

1. Initialize App with freshnessTesting set to true

import { App } from "@tinyhttp/app";
new App({
    settings: {
        freshnessTesting: true
    }
})
    .get("/", (_, res) => res.send("Things"))
    .listen(8080, () => console.log("Listening on port 8080"));

2. Open localhost:8080 in the browser
3. Refresh
4. Both requests sent got HTTP code 200, even though they both have the same ETag

Expected behavior

tinyhttp sends a 304 not modified code on the refresh, so the browser gets it from it's cache.

Versions

• node: 16.3.0
• @tinyhttp/app: 1.3.8

tests are almost identical to Express session module, so there are references to source of their tests.

• [ ] SessionManager(opts)
  • [ ] more coming soon....
• [ ] getSession(req, res)
  • [x] session.save(cb)
    • [x] Should save session to store (src)
    • [x] Should prevent end-of-request save (src)
    • [x] Should prevent end-of-request save on reloaded session
  • [x] session.touch(cb) (src)
  • [ ] session.cookie (src)
  • [x] session.originalMaxAge (src)
  • and the rest of session properties :D
• [ ] Cookie
  • [ ] new Cookie(opts)
    • [x] expires is falsy be default
    • [x] httpOnly is true by default

this list is in progress, so pls ping once finished writing those tests

Is your feature request related to a problem? Please describe.

It adds emoji badges for better readability

Describe the solution you'd like

Add badges setting with 2 sub-settings to be used like this:

app.use(logger({ badges: { emoji: true, captions: false }))

Default values are both false - if badges: true - only toggle emoji. if an object is present - check for the settings.

first setting toggles emoji badges, like this :warning: second enables emoji alt text (in case emoji fails to display or just prefer the text instead), like this: warning

here's a table of emoji / texts:

| emoji | text | status code | |-----|-------|----------------| | :x: | Error | 500 | | :warning: | status message | 4XX (Except 404) | | :ok: | OK | 2XX | | :mag_right: | Not Found | 404 |

Should be logged in the beginning:

🆗 GET 200 OK /css/shared.css

Additional context

Zoya logger that has emoji:

Describe the bug

The sirv or serve-static middleware does not serve files when putting it under another path in the router. It does work when the mount path is / or corresponds with the filesystem.

To Reproduce

import { App } from "@tinyhttp/app";
import serveStatic from "serve-static";
import sirv from "sirv";

new App()
  .use("/static", sirv("dist/client"))
  .use("/static2", serveStatic("dist/client"))
  .use("/pages", sirv("dist/client"))
  .listen(3000);

$ curl http://localhost:3000/static/pages/index.js
Not found
$ curl http://localhost:3000/static2/pages/index.js
Not found
$ curl http://localhost:3000/pages/index.js
console.log("hi");

Expected behavior

$ curl http://localhost:3000/static/pages/index.js
console.log("hi");
$ curl http://localhost:3000/static2/pages/index.js
console.log("hi");
$ curl http://localhost:3000/pages/index.js
Not found

Versions

• node: v14.13.0
• @tinyhttp/app: ^1.0.14

Additional context

$ tree dist/client
dist/client
└── pages
    ├── index.js
    ├── index.js.map
    ├── outdex.js
    └── outdex.js.map

Create a server-side Google-like search, similar to Express search example

example folder: search

Redis can be used, although it isn't a necessity

a simple array will also work

a bonus point would be making a cool layout for it (google clone but w/ tinyhttp logo idk) :D

Describe the bug

I write a simple web service using tinyhttp and i decided to deploy on heroku. but guess what, heroku don't compatible with tinyhttp. when i replaced tinyhttp with express, everything works fine.

To Reproduce

Steps to reproduce the behavior:

1. write webservice
2. add Procfile
3. set web: yarn start
4. git add -A
5. git push heroku master

Expected behavior

Working Fin!

Versions

• node: 14
• @tinyhttp/app: 0.4.1

Additional context

Sooooo, I am having a new issue: the first response gives an actual error/result (which is expected), but on the second request it responds with my 404 noMatchHandler.. It doesn't matteer what the url is on the second request, it just sends the 404 and then complains the headers are already sent.

francel@francel-Inspiron-N5010:~/Images/typescript$ npm start

start node --experimental-loader ts-node/esm --experimental-specifier-resolution=node index.ts

(node:25298) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time (Use node --trace-warnings ... to show where the warning was created) internal/modules/cjs/loader.js:889 const err = new Error(message); ^

Error: Cannot find module 'typescript' Require stack:

• /home/francel/Images/typescript/node_modules/ts-node/dist/index.js
• /home/francel/Images/typescript/node_modules/ts-node/dist/esm.js
• /home/francel/Images/typescript/node_modules/ts-node/esm.mjs at Function.Module._resolveFilename (internal/modules/cjs/loader.js:889:15) at Function.resolve (internal/modules/cjs/helpers.js:98:19) at loadCompiler (/home/francel/Images/typescript/node_modules/ts-node/dist/index.js:163:34) at create (/home/francel/Images/typescript/node_modules/ts-node/dist/index.js:170:28) at Object.register (/home/francel/Images/typescript/node_modules/ts-node/dist/index.js:139:21) at Object.registerAndCreateEsmHooks (/home/francel/Images/typescript/node_modules/ts-node/dist/esm.js:22:36) at file:///home/francel/Images/typescript/node_modules/ts-node/esm.mjs:11:9 at ModuleJob.run (internal/modules/esm/module_job.js:170:25) at async Loader.import (internal/modules/esm/loader.js:178:24) at async internal/process/esm_loader.js:57:9 { code: 'MODULE_NOT_FOUND', requireStack: [ '/home/francel/Images/typescript/node_modules/ts-node/dist/index.js', '/home/francel/Images/typescript/node_modules/ts-node/dist/esm.js', '/home/francel/Images/typescript/node_modules/ts-node/esm.mjs' ] } francel@francel-Inspiron-N5010:~/Images/typescript$

Describe the bug

When a subapp is mounted on a path, all of the middlewares with the same path in the original app are ignored and return 404 because it's being handled by a subapp.

To Reproduce

import { App } from '@tinyhttp/app'
import serveStatic from 'serve-static'
import sirv from 'sirv'
import path from 'path'

const app = new App()

const subapp = new App()

subapp.get('/',(req, res) => res.send('hello world'))


app.use('/', sirv('public'))
app.use('/', subapp)

app.listen(3000)

$ curl localhost:3000
hello world
$ curl localhost:3000/hello.txt
Not Found

Expected behavior

If subapp couldn't find the handler with the request path, the original middleware should handle it instead.

$ curl localhost:3000
hello world
$ curl localhost:3000/hello.txt
I am a file

Versions

• node: 15.4.0
• @tinyhttp/app: 1.1.0

Additional context

#203

Currently, ctrl+click on a tinyhttp export from VS Code goes to the .d.ts file instead of going to the function source code. Adding "declarationMap": true to tsconfig.json would generate .js.map files. For example, take a look here https://github.com/wingedrhino/node-pipespawn/tree/master/dist

I'd love to add this to tinyhttp, but every other package that's been moved to its own dedicated repository would also need to be updated for this to be actually useful.

If you're happy to accept merge requests, I can start submitting them one at a time!

Closes #351 by un-defining the default server host name and adds a new test which passes on dual-stack machines.

Sadly, this may not be testable on GitHub due to actions/virtual-environments#668.

Describe the bug

If you create a basic server and don't specify an address to bind to, the server will bind to 0.0.0.0. On an OS with both IPv4 and IPv6, this may mean it will reject requests to localhost.

To Reproduce

Steps to reproduce the behavior:

1. install and run the basic example
2. open http://localhost:3000 in a browser, see "Hello World" message.
3. http://127.0.0.1:3000/ works too.
4. open http://[::1]:3000/ (IPv6 loopback address) - fails

Expected behavior

You should see the same "Hello World" in all cases. A server without a specified host should listen on all available interfaces.

Workaround: change line 25 of index.js to this:

.listen(3000, () => console.log(`Listening on http://localhost:3000`), "::")

Versions

• node: 17.6.0
• @tinyhttp/app: 2.0.19

Additional context

I personally found this while trying to use tinyhttp to power the API backend for a Vite frontend, and doing local testing using Vite's built-in proxy. The frontend was running on http://localhost:3000 and the backend was using http://localhost:3001. Accessing both services through a browser was fine, and also running the whole stack inside of docker compose was OK too. But on my MacBook (macOS 12.2.1) using Node v17.6.0, attempts to proxy to the backend resulted in this error:

Error: connect ECONNREFUSED ::1:3001
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1158:16)

...until I changed the app.listen line in my server to add the last argument with the value "::".

app.listen(PORT, () => console.log("Started on http://localhost:" + PORT), "::");

It turns out that a blank string "" also works. On my machine at least, IPv6 seems to have higher priority than IPv4. AFAICT, this behavior appears to have been changed in GH-86 to fix #85. According to the relevant Node documentation for server.listen:

If host is omitted, the server will accept connections on the unspecified IPv6 address (::) when IPv6 is available, or the unspecified IPv4 address (0.0.0.0) otherwise. In most operating systems, listening to the unspecified IPv6 address (::) may cause the net.Server to also listen on the unspecified IPv4 address (0.0.0.0).

This suggests that in addition to the workaround above (that is, using host value "::" instead of "0.0.0.0"), perhaps omitting the host by making the default host an empty string is the right call, and let Node sort it out.

The reasoning behind dual-stack interface binding is discussed further in nodejs/node#9390.

By the way, great library and documentation. Thanks for your work on this over the years.

Now that @tinyhttp/router v1.0.5+ no longer depends on http module of Node.js, it should be very easy to implement basic Deno support for tinyhttp. Probably it would be cool to have it located in the separate deno folder with all editor settings specifically for it.

There aren't strict requirements on how it should be implemented, but i suppose we need to use either raw gh links, jspm or skypack to import the router

and we should use Deno's std http lib to pass request and response as generics, e.g. smth like this:

import { Router } from 'https://...'
import { ServerRequest } from 'https://...'

export class App extends Router<ServerRequest, ...> {
 // ...
}

so it works instantly

Is your feature request related to a problem? Please describe.

An adaper for Nest will let you use tinyhttp inside of Nest instead of Express.

Describe the solution you'd like

A Nest.js adapter package, something like @tinyhttp/nest-adapter

Additional context

• NestJS platform-express
• nestjs-platform-polka

Please pull request to this repository

Create a real-world application, a Medium clone, according to this repo spec

Stack:

| tool | name | |------------|-----------------------------| | web framework | tinyhttp (obv) | | body parser | milliparsec | | database | PostgreSQL | | ORM (ik it's not but it's easier to call it like this) | Prisma | | auth | JWT (w/ @tinyhttp/jwt) | | cors | @tinyhttp/cors | | unit tests | uvu + supertest-fetch |

The whole code must be in a separate repository and the PR only needs to include a link to that repository.

example readme:

RealWorld

Example tinyhttp Medium clone following the RealWorld spec.

Check the node-tinyhttp-realworld-example-app repository.

p.s.: after completing an example, either me or the one who made the repo should open an issue to realworld repo and after that, submit a PR