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.

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

Serve assets from public/ instead of . #503

Closed
tal opened this issue Aug 26, 2016 · 11 comments · Fixed by #551
Closed

Serve assets from public/ instead of . #503

tal opened this issue Aug 26, 2016 · 11 comments · Fixed by #551
Milestone

Comments

@tal
Copy link

tal commented Aug 26, 2016

By serving assets from the root directory you cannot have routes that have names the same as the folders built in such as src or any other you add to the app.

If we put index.html and all other static assets within a public folder this would only expose the assets that are needed.

@tal
Copy link
Author

tal commented Aug 26, 2016

A little sad that issue 503 isn't a crashing bug 😞

@gaearon
Copy link
Contributor

gaearon commented Aug 26, 2016

By serving assets from the root directory

Are we serving assets from root directory? If we are, we should disable that. We never intended this to be the case.

@tal
Copy link
Author

tal commented Aug 27, 2016

eg hitting http://localhost:3000/src/ it will show the contents of the folder and any file within is shown.

@gaearon
Copy link
Contributor

gaearon commented Aug 27, 2016

Um, this certainly was not the intention.
Would you like to send a PR to disable this?
I imagine some WDS option does it.

@gaearon gaearon added this to the 0.3.0 milestone Aug 27, 2016
@tal
Copy link
Author

tal commented Aug 27, 2016

Would you be opposed to the creation of a public directory to house all static assets? Honestly not 100% sure if there's another way to do this other than making an assets folder that would house all static assets and be accessible via localhost:3000/assets/my-asset.jpg

@gaearon
Copy link
Contributor

gaearon commented Aug 27, 2016

What is the use case for doing that, as opposed to importing asset files from JS?

@davidascher
Copy link
Contributor

davidascher commented Aug 27, 2016

If I understand this bug correctly, serving favicon like files for things like iOS etc requires something like it:

<link rel="apple-touch-icon" sizes="180x180" href="/static/icons/apple-touch-icon.png">
<link rel="icon" type="image/png" href="/static/icons/favicon-32x32.png" sizes="32x32">
<link rel="icon" type="image/png" href="/static/icons/favicon-16x16.png" sizes="16x16">
<link rel="manifest" href="/static/icons/manifest.json">
<link rel="mask-icon" href="/static/icons/safari-pinned-tab.svg" color="#0f7852">
<meta name="msapplication-config" content="/static/icons/browserconfig.xml">

I currently have a static dir in my root, and then a build task that moves the directories in that directory in the build tree after npm build. Don't know how else to serve those assets both in dev and prod.

@gaearon
Copy link
Contributor

gaearon commented Aug 28, 2016

@davidascher I think that use case will be addressed by #226 and #413.

@tal
Copy link
Author

tal commented Aug 28, 2016

Agreed, those PRs seem to be sufficient.

@tal
Copy link
Author

tal commented Aug 29, 2016

Looking now i dont think #226 is sufficient. I'd propose hoisting index.html into src and having the other static files included via webpack in some way.

@davidascher I stated it in #226 but having a static folder I think would be a mistake because it provides 2 places for assets to go without a clear reason for them to be in any particular location. All of the assets in your example do not require a specific name so could go though transformations to gain cdn busting abilities and a unified pipeline.

I guess this issue is really asking for a way to have webpack parse and replace static files within the index.html? as well as disable webpack dev server's serving of assets that aren't linked to properly.

@gaearon
Copy link
Contributor

gaearon commented Sep 22, 2016

That’s the approach I’m going to take in 0.5.0.

@lock lock bot locked and limited conversation to collaborators Jan 22, 2019
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 a pull request may close this issue.

3 participants