feat: Implement a way to expose static files from a directory (similar to Python SimpleHttpServer)

[ErickWendel]

What is the problem this feature will solve?

HTTP Server is a very popular package with 1M+ weekly downloads used to expose static files from a directory.

Node.js doesn't have any native way to expose static files in a directory from a single command.

This is an idea given by @ruyadorno during a session on Tooling WG at nodejs/tooling#164 which he suggested I implement it.

What is the feature you are proposing to solve the problem?

In Python, they have the SimpleHTTPServer a native module meant for the development environment and has basic security checks.

The idea is not to replace the HTTP Server package, as it's a robust package, but to have a similar implementation to Python's SimpleHTTPServer exposing directory files.

Adding something like:

node --serve directory -p 3000

or

node --serve . 
#with a default port

What alternatives have you considered?

No response

[richardlau]

FWIW we use the Python equivalent for the docserve target in our Makefile:

node/Makefile

Lines 835 to 837 in eb298df

	.PHONY: docserve
	docserve: $(apidocs_html) $(apiassets)
	@$(PYTHON) -m http.server 8000 --bind 127.0.0.1 --directory out/doc/api

[ErickWendel]

FWIW we use the Python equivalent for the docserve target in our Makefile:

node/Makefile

Lines 835 to 837 in eb298df

	.PHONY: docserve
	docserve: $(apidocs_html) $(apiassets)
	@$(PYTHON) -m http.server 8000 --bind 127.0.0.1 --directory out/doc/api

Nice! this way we can move from Python and use Node only for it 🤩

[DominusKelvin]

This looks great. I'm interested in seeing how the implementation goes.

[Trott]

@nodejs/tsc @nodejs/http

[ShogunPanda]

Same here, really interested in this. Let me know if I can help with the implementation.

[GeoffreyBooth]

The maintainers of http-server should be consulted regarding this. It's considered impolite for Node to supplant a popular public package without doing outreach first.

[DominusKelvin]

Good point at @GeoffreyBooth.

@ErickWendel how much overlap will there be with the http-server package as you mentioned the plan is not to replace it completely?

[mcollina]

I don't think we should be implementing https://www.npmjs.com/package/http-server in core.
I believe that we should bring https://npm.im/send in and make it significantly faster, ideally with some parts implemented in C++ to bypass some of the problems.

[targos]

I don't think we should be implementing https://www.npmjs.com/package/http-server in core.

You mean http-server specifically, or the feature it provides (a simple way to spawn a local file server)?
If it's the latter, why?

[mcollina]

I think we should offer the functionality to serve static files in core, ideally with a superior implementation than send(). Serving files in JavaScript is highly inefficient.

@jasnell did some part of the work for http/2, however, it lacks quite a few features to be complete (etags, ranges, directories, etc).

We might also provide some utility that could enable us to do:

node -e "require('http').createStaticServe({ path: './static' }).listen(3000)"

I don't think we should offer a --serve flag because there are a lot of possible configuration options for a web server. Moreover, http-server offers additional features such as a full-blown reverse proxy. Those latter functionalities are pretty helpful and I do not think we should compete with the ecosystem on this.

[Trott]

Serving files in JavaScript is highly inefficient.
...
I don't think we should offer a --serve flag because there are a lot of possible configuration options for a web server.

What if we choose not to worry about configurability or efficiency? For example, what if it:

• Only serves on localhost.
• Is not configurable beyond specifying a port number and maybe a few other narrow and obvious things. It serves a directory, maybe knows about the usual relevant MIME types for file extensions, etc. No fiddling with keep-alive, TLS, etc. No reverse-proxy. And so on.
• Is documented with a very big warning about how it is not a production-ready web server, is inefficient, insecure, for testing and development only, etc.,

Valid use cases would be:

• I have built a static web site and want to look at it and/or test it locally before deploying it.
• I have a docs directory that I want to look at in a web browser.
• I want to set up a web server locally for a static directory so I can run a link checker locally.

Invalid use cases would be:

• I want to serve a static directory to others in a production environment.
• I need to test performance and efficiency using different server options.
• I need a reverse-proxy.