It seems there is the following error in request documentation:

const hello = (url, method) => {
  return "Hello from " + method + " " + url
}
route.define([
  route.get("/", ["method", "url"], hello)
])

I suppose parameters of hello function should be method, url.

Exactly where http range implementation goes (in the node http adapter or as middleware) I don't know yet, inclined towards middleware (as an external lib).

spirit-express will need to be updated to include this for Express middleware that support range requests too (like webpack-dev-middleware).

As for the response, there is no change needed to support this, however a helper function for generating a range response would be useful. Though again I do not know if it fits into the core functions provided by spirit.

Moving this to one issue to track better. See #2

How does this work with spirit? It's a really important part of any webserver.

Would be nice to have an example in the guide an possibly even an included parser in spirit (like ['ip', 'headers']).

Any help is appreciated, even if it's just telling me where I can find the information needed to assemble the body myself.

It would be nice if Spirit had this( url_for, urlFor, pathFor...)

Hi,

It would be very nice if there would be a middleware handler for koa like you did it with spirit-express.

Is there any HTTP 2 support for spirit? Is it possible to implement this with the current middleware API?

Combining resources would be the most important bit for my use-case, since I'm trying to reduce the initial latency of first loading a .js and then letting that .js load a .css. Due to caching issues it's unfortunately not possible to do both at the same time, except by using HTTP 2.

I have an Angular project and I am trying to import a Spirit animation.

I have installed the spirit npm package via
npm i spiritjs

I have added the script to the list of loaded scripts
"scripts": ["./node_modules/spiritjs/dist/spirit.js"]

Now, when I try to import the module into one of my modules and use it in appComponent:
import * as spirit from 'spiritjs';

constructor() {
spirit.loadAnimation({...})
}

TS throws 2 errors:
ERROR in node_modules/spiritjs/spiritjs.d.ts(1,64): error TS2307: Cannot find module 'gsap'.
src/app.component.ts(24,12): error TS2339: Property 'loadAnimation' does not exist on type 'SpiritStatic'.

I just wanted to understand why you did not include the package-lock.json. Is it maybe you do not want to resolve any merge conflicts in the package-lock.json ( cause boi that shit is a nightmare ) if one does occur or you thought not really that necessary. I think it would be helpful to include that I or someone else does not accidentally install package that is not compatible with the packages on your local version of the project a version or a diff that might break the project.

Hope you have a great day or night 😄

This issue is closed in favor of the Roadmap wiki page.

This is a road map for remaining work.

It's all listed in one place, so it's easy to see what is missing, and what is planned.

Contributions are welcomed, and I can assist you if you have any questions. I marked them with easy, medium, difficult.

• http2 support for node http adapter [easy]
  Possible solution: node http adapter's response spec should be updated to support an additional key (property) for pushing files in http2.
• support http range requests [medium]
  Possible helper function for creating a partial range response.
• logging & debugging output
• etag generating middleware [easy]
  Currently there is a middleware for sending back 304 responses when ETags match, but there is no middleware for generating a ETag.
  Ideally this should re-use an existing solution (library) if possible.
  The middleware should auto-generate Etags for file resources when the response body is a file stream, otherwise all other response bodies should be left alone. (Unless the response body is huge).
• Response.cookie
• Website
  Mostly important to have a single place where all help resources can be found.
• spirit-defaults [medium]
  It is a project meant to reduce boilerplates and typing for a lot of common middleware

Internal

• _destructure from spirit-router is working but can use a review [easy]
• resource from spirit-router could also use a review and be tested better [medium]

Can we get a performance benchmark between Spirit and Fastify ?

Hello,

I'm building a JSON api using spirit.
I've started by adding catch-all route to return 404 response.

route.get("*", {
  status: 404,
  headers: {
    'Content-Type': 'application/json'
  }
    body: JSON.stringify({
    message: 'Not Found',
  })
})

While it works, it's a little bit verbose.

Is there a shorter way to do that, maybe something like:

route.get("*", response.json(404, { message: "Not Found" }))

Thanks,
Ran.

Hi,

great work. I like it.

But for package quality it would be nice if you optimise your .npmignore.

README and LICENSE should be in the package and CHANGELOG is OK.

But the _book, docs and spec directories blow up the package and the end user doesn't need a Makefile or CNAME (for example).

I could send you a PR but it's only a little change and you know best what you want to see if you look into node_modules/spirit.

There's a small bug/unexpected behavior in this function.

Minimal Repro

const headers = { cors: { 'Access-Control-Allow-Origin': '*' } }

require('http').createServer(
	require('spirit').node.adapter(r => r.path === '/bug' ? {
		status: 200,
		headers: headers.cors,
	} : {
		status: 200,
		headers: headers.cors,
		body: 'Not Empty',
	})
).listen(8080)

Request 1: curl "http://127.0.0.1:8080"

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Length: 9
Date: Wed, 18 Apr 2018 21:06:35 GMT
Connection: close

Not Empty

Request 2: curl "http://127.0.0.1:8080/bug"

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Length: 0
Date: Wed, 18 Apr 2018 21:07:05 GMT
Connection: close

Retry request 1: curl "http://127.0.0.1:8080"

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Length: 0
Date: Wed, 18 Apr 2018 21:07:30 GMT
Connection: close

What exactly happens?

Spirit tries to add Content-Length: 0 to the response headers, but those also get added to headers.cors, making all bodies that will ever be sent vanish.

I'm thinking of adding some Typescript definitions to the project to offer a better developer experience for anyone working with Typescript.

Has any work been done on this yet and if not to what extent do you think this project should be integrated with Typescript ( A definition file vs adding types to the codebase )?

I really appreciate the nice little project over here. But besides performance, isnt the API of spirit essentially similar to koa2? in spirit, middleware looks like
(handler) => (request) => handler(request)
which is similar, though more smooth, than koa2's
(ctx/* == request*/, next) => next()
I can't see advantages in the route definition, since if you're returning a response map, you're transmitting HTTP information too.
e.g. a route in spirit might be
route .define([ route .get ("/", [], () => { return "Hello World!" }) ])
whereas in koa2 i might do

var route = () => { return "Hello World!" };
app .use ((ctx, next) => { ctx .body = route (/*or whatever dependencies need be injected*/); return next (); })

I really enjoy the simple API of spirit, but I feel it might have made a bad distinction between routes and middleware; when routes have to return response maps, i feel that wouldve more elegantly been made as a middleware by default. Even more impure seems to be the dependency injection in the request; once again I feel like its the job of a middleware. If spirit aims to be pure, lets go all pure!

It would be great if there is a way to pass values to a global container for use in templating engines for example.