-
Notifications
You must be signed in to change notification settings - Fork 693
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.
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
Please add back support for -s option for the sake of CRA users #382
Comments
Also, the -p option has been removed. We have switched to using serve@v6 rather than latest in our Dockerfile.
|
Just jumped on DM with @gaearon and we figured out a great solution. Sorry for the inconvenience we've caused. I will personally ensure that this won't happen again! The latest release of {
"source": "**",
"destination": "/index.html"
} Effectively making CRA apps work just as before again. For @sjdweb, we also have a solution: Please just pass |
Thanks 💜💜💜 |
TL;DR: always lock down your dependencies. For anyone coming here, I'd like to suggest an extra fix for devs who got this problem. We were manually installing
Which just started causing the strange error The better way IMHO is to install
Then |
Hi 👋
As you might know, Serve is currently featured in production build instructions of every single app created with CRA. We didn’t add it to CRA ourselves—we took a PR from @leo (facebook/create-react-app#1760). It’s a nice tool indeed! Zeit is doing a lot of important work in the React ecosystem, and at the time I thought it would be a nice gesture to recommend it too.
When we took that PR we assumed that
serve
is a simple utility that wouldn’t change in important ways for such a simple (from the user’s point of view) use case as serving a single static folder for an SPA.However, this changed with Serve 7. Specifically, the
-s
option was dropped. This means that every single app made with CRA now prints wrong instructions: #379.Now I agree that normally it would be our fault for including an instruction in the build output without specifying the version. But again, we didn’t add
serve
ourselves to CRA. We took a PR from the Zeit team (facebook/create-react-app#1760). That PR didn’t include a version number so I thought there was an implicit assumption this part of the Serve API isn’t going to change.This is ultimately my fault for relying on something external in the instructions. But the current situation is deeply confusing to our users, and I hope you can help. Quoting #379:
There are several possible solutions.
We could take facebook/create-react-app#4532. Note this is neither simple nor exhaustive. It means I would have to drop everything I’m doing, and release patch releases for every major version of
react-dev-utils
that contains this text.This still wouldn’t be sufficient either because, as you can see in facebook/create-react-app#1760 (which is where the instructions were added for the first time), they used to be a part of
react-scripts
itself! So there is just no possible way to release this change for people pinned to a specificreact-scripts
version. In practice it means that all apps older than a certain version will keep printing wrong instructions.Our philosophy is that people shouldn’t feel obligated to upgrade their toolchains, and it is sad that their projects will now be confusing to everyone who runs them. This includes both apps and open source examples and demos through which people learn React.
And of course, people who ejected before it was moved to
react-dev-utils
just have that message hardcoded into their build scripts. There is no way we could fix it.Even if we take facebook/create-react-app#4532, it seems like it does something different now (without
-s
the whole point of usingserve
is lost for us). Using a config file is not an option for us, and is pretty much a showstopper for CRA. This has to be a simple single command.So this means that we’ll not only have to do all the work above (and it will not be sufficient, as I explained, because many people will still see the old message), but also quickly find a maintained replacement before too many people get confused by their broken build testing instructions.
An alternative solution would be to keep
-s
. How complex would you estimate this to be?If you’re convinced dropping it is best, is there any chance you could give us at least a few weeks to do those patch releases and do our best effort at updating the messages where it is possible? Maybe once we figure out another tool to migrate to, you could make
serve -s
print a message that also recommends it? At least this way old projects would still print something sensible.To be clear, I’m not concerned for myself. This is just very unfortunate for our users and especially beginners who learn not to trust what their tools tell them.
The text was updated successfully, but these errors were encountered: