Dev server with the "dumb" hot reloading

[zindel]

I've started the refactor this weekend with the main goal to provide the accurate and machine-friendly reporting using the --report=json option. If you're curious see the refactor/flat-packer branch. In fact this is just the beginning of it. I'm also planning to optimize and re-structure the production mode bundling (tree-shaking), but that'd take another week or two.

In this issue I wanted to start the discussion and ask for some help implementing the integration with the dev server. I am not really experienced with the Node-based backend development, so any feedback or prototyping is much appreciated.

The server may work as following:

1. Accept few basic options required for running (--host, --port, etc) + all the fastpack original options (except maybe --development which is always set and --report which is always set to json).
2. Start the fpack process in a watch mode with the provided options and capture its stdout/stderr.
3. Start the web socket server and inject the websocket client code to any html file served.
4. On receiving the "ok" event from fpack ping clients and ask them to simply reload the page.
5. On receiving the "error" event - send the error to clients. They will have to show it in the browser.

Thank you!

[rauanmayemir]

I'm currently working on a small react app and using webpack's dev server with hot reloading. Would love to give pointers and help with testing. (will try to contribute as well, but I'm a bit stretched these days).

[TrySound]

@rauanmayemir Thanks. I will ping you when it will be ready for testing.

[matthiaskern]

I could help with testing on another react app which has cra-like setup. Would also be interested in directly contributing if there are any low-hanging fruits.

[shellscape]

Former maintainer of webpack-dev-server, and current maintainer of webpack-serve, webpack-hot-client, webpack-dev-middleware (...the list goes on). I'd be happy to help get a dev server going for you all (that is of course, if it was cool if JavaScript was used - I'm afraid I'm not a ReasonML dev)

[zindel]

@shellscape Thanks for offering the help! Mind if we ask you to review & provide feedback on the @TrySound's initial implementation? And yes, we plan to use JavaScript for it

[shellscape]

@zindel absolutely, can you point me in a direction towards it?

[zindel]

@shellscape will do once @TrySound has something ready :) @TrySound do you mind if we keep it in one repo/npm package for now? We can place it in node-service/ if you don't mind.

[TrySound]

@zindel I thought about providing apis like this

import { build, serve } from 'fpack';

build({
  // options
})

serve({
  // options
})

[zindel]

@TrySound maybe we can postpone creating the JS API for now? I think the fpack API may change significantly and JS API will go out of sync. I think the ideal solution would be to blindly pass the remaining command-line options to the fpack binary and let it do its job. Some knowledge is obviously needed though:

• always pass --report=json
• always pass -w
• always pass --development

Everything else may go as is. Thoughts?

[andreypopp]

I think a simple idiomatic JS API is needed, we can’t expect people providing command line arguments when using fastpack from node. We can use a simple mapping bug from JSON to command line arguments though.

…

On Tue, 10 Jul 2018 at 09:39 Oleksiy Golovko ***@***.***> wrote: @TrySound <https://github.com/TrySound> maybe we can postpone creating the JS API for now? I think the fpack API may change significantly and JS API will go out of sync. I think the ideal solution would be to blindly pass the remaining command-line options to the fpack binary and let it do its job. Some knowledge is obviously needed though: - always pass --report=json - always pass -w - always pass --development Everything else may go as is. Thoughts? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#92 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB3gsIA2Qjx4srjjAvtxCMi4ONRhL-iks5uFEwTgaJpZM4VHMXf> .

[zindel]

We have agreed on just serve for now which is not going to be public (yet).

[TrySound]

Guys, I'm busy these days. It's better to somebody else take this issue. @shellscape would be great to have your experience in this.

[ulrikstrid]

I hacked this together: https://github.com/ulrikstrid/fpack-dev-server

I should take a look at what @shellscape has done in the various webpack-dev-server packages to make it more robust etc but this is a really simple start.

[shellscape]

webpack-serve and webpack-hot-client are the two to check out. webpack-dev-server is a tire fire.

[ulrikstrid]

@shellscape if you want to take this feel free. If you don't I'll slowly continue.

Thanks for the pointers!

[shellscape]

It'll be a few weeks for me (offline is crazy right now, including an inoperable thumb of all things), but I'll star your repo and see about where I can help your effort when I'm able.

[ulrikstrid]

There is an open PR but I also have this playground repo that I've been toying with if anyone is interested to have a look https://github.com/ulrikstrid/fastpack-devserver-playground.

It basically works but I need to add more inputs with cmdliner and also have a real implementation of a websocket client that gets injected into the html or something like it.