Skip to content
This repository has been archived by the owner on Feb 15, 2023. It is now read-only.

Proposing that --single to npm run dev #116

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

johnpapa
Copy link

@johnpapa johnpapa commented Feb 24, 2020

I propose that the flag --single be added to the npm run dev script. This will allow fallback routing to work with the development server.

This is important as new folks use this template to get started. When they add client side routing and they refresh on a client side route, the current behavior will result in a 404. By adding --single this will "just work"

This is documented in the readme here, but I believe that this should be the default.

cc @mindrones @softchris

I propose that the flag `--single` be added to the `npm run dev` script. This will allow fallback routing to work with the development server. 

This is important as new folks use this template to get started. When they add client side routing and they refresh on a client side route, the current behavior will result in a 404. By adding `--single` this will "just work"

This is documented in the readme here, but I believe that this should be the default.
@lukeed
Copy link
Member

lukeed commented May 29, 2020

This goes back and forth constantly.

@pngwn
Copy link
Member

pngwn commented May 29, 2020

What is the argument against?

@pngwn
Copy link
Member

pngwn commented May 29, 2020

So this is because it is dev only and if you deploy to a different static file server then you will be surprised, I guess.

I don’t know if there is a good solution to this. You probably should be using a different setup when it comes to deploying but on the same token, emulating desirable prod behaviour seems a reasonable ask.

I feel like some documentation on how best to deploy in a reliable manner might be a better solution than just disabling something makes for a nicer dev experience out of the box.

If people get confused about having no wildcard redirect to root when deploying then we could at least point them to the deployment documentation easily enough.

@lukeed
Copy link
Member

lukeed commented May 29, 2020

The issue was that people would have missing assets and be viewing their homepage content, or get unhelpful "unexpected token" errors in their console for missing js files.

I think the solution is coming with sirv@1.0 which will have a default set of "ignore me" paths when SPA mode is enabled.

@antony
Copy link
Member

antony commented Aug 27, 2020

@lukeed can this be closed since the bump to sirv 1.0.0 fixes the issue?

@lukeed
Copy link
Member

lukeed commented Aug 27, 2020

Depends. The 1.0 removes the primary headache/reason we had for removing it, but may not be wanted by default. Think there are still mixed opinions on this amongst ourselves, but my opinion is that it should be on

@guidobouman
Copy link

guidobouman commented Dec 5, 2020

What are the responsibilities of this template?

If you ask me, it would be this:

Allow an easy point to get started, no matter what your style is, be it separate pages or SPA's.

I think that goal has precedence over conformity with deployment environments.

Some environments even setup the redirects for you. Firebase for example asks if you plan to deploy an SPA, and will setup redirect rules automatically. For those environments, the template is suddenly not providing the easy setup it promises to deliver.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants