How to use with react-router browserhistory

[jonaskello]

In order to work with browserhistory the server needs to serve index.html to all request, with the exception of actual static content of course. I did not find a way to solve this with jspm-hmr server. I'm currently using hashHistory but need to switch to browserhistory so I need to solve this somehow. Maybe I could try to make a PR if this is something you want to add?

[piotrwitek]

Yes I think it would be useful so let's work together to add it.
I believe It would be good to add it as a config flag to not break existing default behavior e. g. "always serve index. html for SPA"
The solution would require to add route rules to the running http server listener and set it to always serve index with exceptions to static assets like you mentioned, what do you think, make sense? please add your remarks below.

[jonaskello]

Yes, I think putting as an additional options makes sense. I guess we could use express-history-api-fallback and express-history-spa-fallback as inspiration on how it should work, but since the package is not using express we cannot use them directly. From what I understand by reading the code it is using http-server. I have also used that package but only as a command line tool. Not sure how to configure it from code. I also noticed a TODO here about switching to core http module. If you are thinking about removing the dependency on http-server maybe we should do it at the same time? Or if http-module is easy to configure with routes maybe it should be kept?

[jonaskello]

Thinking about it a bit more, the easiest way to implement it would probably be to switch to express and use the existing fallback packages (enabling them by a config option). Although that would create more dependencies for this package and my general opinion is that fewer external dependencies is always better so for that reason I don't like that solution. On the other hand this package is only used for dev, so having more dependencies that makes the size of the package larger would probably not be a problem. What do you think?

[jonaskello]

Not really related to this but to start working I did a fork and updated to typescript 2.0 including the use of @typings instead of typings. You can have a look here:

https://github.com/jonaskello/jspm-hmr/tree/fallback_express

EDIT: Here is the compare view

master...jonaskello:fallback_express

[piotrwitek]

I'm travelling now, gonna check it tomorrow. If implementing with core http module is too much effort, let's go with the express way.

[jonaskello]

I have it working now by using express, you can check when you have time. I have added a new option called fallback that can be used to specify a file that should be returned for all missing routes. I have only added it to the API, there is no CLI option yet.

The compare link above should show all changes. Many of the changes are related to migrating to @types. Also I had to make an own node_modules folder in order to have custom typings, this should not be needed anymore when this issue is resolved in ts 2.1, then we can put the typings in any folder we want. EDIT: I found a better workaround, now I use path mapping in tsconfig to point to the custom typings.

If you think it is too many changes, I could make a new branch and just apply the changes needed for the feature and not do migration to @types.

[piotrwitek]

I believe making seperate branch for @types updates will be better to merge, I'll take care of it tommorow

[piotrwitek]

Added browser history api fallback to jspm-hmr dev server - for working example of how to use it check in related JSPM starter project piotrwitek/react-redux-typescript-jspm-starter@9c097cb