Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix for #625 broken historyApiFallback #627

Merged
merged 2 commits into from
Sep 28, 2016
Merged

fix for #625 broken historyApiFallback #627

merged 2 commits into from
Sep 28, 2016

Conversation

mac2000
Copy link
Contributor

@mac2000 mac2000 commented Sep 28, 2016

fixing broken historyApiFallback, with this one - tests are passed and we can use custom index or rewrites property of historyApiFallback

@SpaceK33z SpaceK33z merged commit 0d3a707 into webpack:master Sep 28, 2016
@SpaceK33z
Copy link
Member

Thanks!

@aves84
Copy link
Contributor

aves84 commented Sep 28, 2016

@SpaceK33z And serving the files without extensions or with disableDotRule is broken again. Great job :/

@SpaceK33z
Copy link
Member

@aves84, this solution doesn't break previous behavior. If you find a solution that doesn't break the old behavior (that is, showing the directory index instead of the page set with historyApiFallback), I'll happily merge a PR.

@aves84
Copy link
Contributor

aves84 commented Sep 28, 2016

@SpaceK33z in #625 I already wrote this solution - you need to extract serveIndex from contentBase to independent meddleware.

I don't interested anymore making PR, everyone of which are reverted :/

I will prefer just to switch back to browserSync with normal behaviour.

SpaceK33z added a commit that referenced this pull request Sep 28, 2016
@SpaceK33z
Fix historyApiFallback, again.
cb1b32f 
The problem earlier with the fix in #627 was that it broke serving files
without extensions (or with `disableDotRule`).

This passed the test because the `disableDotRule: true` was removed; without
this the test will always succeed because without this rule, a request like `/other.html`
will always go directly to the file.
@SpaceK33z
Copy link
Member

@aves84, I can understand your frustration. I didn't understand your solution in #625, but now I get it.

The commit cb1b32f should fix the behavior for both of you. @aves84 and @mac2000, could you verify this? Sorry for the inconvenience.

@aves84
Copy link
Contributor

aves84 commented Sep 28, 2016

@SpaceK33z, for me it works fine, thank you.

@mac2000
Copy link
Contributor Author

mac2000 commented Sep 29, 2016

@SpaceK33z @aves84 confirming things are working with this commit, glad that everyone will be happy again!

@SpaceK33z
Copy link
Member

Great. Thanks for your help!

@SpaceK33z
Copy link
Member

Fix is released in 2.1.0-beta.8.

@SpaceK33z SpaceK33z mentioned this pull request Oct 8, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@mac2000 @SpaceK33z @aves84