"Vendor" folder #28

gaearon · 2016-07-19T22:58:19Z

Let’s wait until somebody asks before implementing but.. I think a vendor folder that just gets copied into the output could be a useful escape hatch. For example, if you have a global script that isn’t UMD-friendly, you want to have some way of importing it. With a vendor folder, you could just put it there, reference it from index.html, and read from window in your bundle.

The text was updated successfully, but these errors were encountered:

gaearon · 2016-07-19T22:58:40Z

https://www.npmjs.com/package/copy-webpack-plugin

frederikcreemers · 2016-07-23T15:21:08Z

This would also be useful for files referenced solely in index.html, like manifest.json, or apple-touchìcon.png, and scripts like web workers and service workers.

gaearon · 2016-07-23T18:51:51Z

This would also be useful for files referenced solely in index.html, like manifest.json, or apple-touchìcon.png, and scripts like web workers and service workers.

Yep.

cliedeman · 2016-07-23T20:29:03Z

Hi there, I just bumped into this issue.

I am trying to implement this using copy-webpack-plugin but I can't figure out how to test my branch.
Are there are notes on doing this?

Ciaran

gaearon · 2016-07-23T20:47:12Z

Does this help? https://github.com/facebookincubator/create-react-app#contributing

Also, we’d need to solve #21 first because this change will also have implications for it.

ForbesLindesay · 2016-07-25T12:20:34Z

vendor doesn't seem like the right name here. Seems more like it should be something like "assets". i.e. this is about serving files that don't need building, not necessarily files that have been vendored in.

gaearon · 2016-07-25T14:22:23Z

Yeah, I agree it’s a bad name. (I don’t like assets because people will immediately think it’s the place to put their CSS and images in.. which it is not.)

Maybe we should just use html-loader and make it that <link href> is automatically rewritten and those files are also processed by webpack. I feel like this could solve the majority of cases (e.g. touch icons or vendor CSS sheets), and even use webpack’s features like content hashes.

baadc0de · 2016-07-26T10:56:24Z

I've been using static for some time now, with good understanding from the rest of the team(s) about it containing purely copied, unprocessed assets. It has been a useful crutch for when a resource path is dynamically generated and/or webpack processing is not required/wanted.

lacker · 2016-07-26T16:07:34Z

I like the name static - it's the folder name Django encourages, and it is also a pretty accurate description of what goes there - the files that are not dynamically generated by some process, but are just a static copy of what's in your filesystem. As opposed to assets which implies that it has to be some sort of image or media asset.

hnordt · 2016-07-26T17:57:06Z

static looks like a better name than vendor or assets.

mxstbr · 2016-07-26T18:39:39Z

I love static, working on a PR now! 🚢

frederikcreemers · 2016-07-26T18:44:44Z

I actually agree with not having a special directory at all. All the
compiled files will be static assets anyway. I think just having babel load
resources referenced by html files would be better. This also gives you
more freedom in your folder structure.

On Tue, Jul 26, 2016 at 7:57 PM Héliton Nordt [email protected]
wrote:

static looks like a better name than vendor or assets.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#28 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAtA1c3w9cK6QqOkQrYcv_Y2gq9yzE7Jks5qZkp4gaJpZM4JQQtC
.

Jul 26, 2016 · 2016-07-26T18:47:45Z

Also worth noting that in general static assets should not go in this directory – they should just be imported and dealt with by webpack loaders. I.e. this is the wrong way to pull in e.g. Bootstrap CSS.

It is a nice escape hatch, ref: #28

timarney · 2016-08-24T18:12:05Z

Bringing this up for discussion as noted in the Readme re:images

I think this style of loading images works for most cases

import logo from './logo.png';
<img src={logo} alt="Logo" />;

I worked on a project pre create-react-app where I had to work with roughly 5000 images.

The images were in directories roughly in this style img/large/building_type/texture_type/colour

Given x # of buildings and x # of colours the path to the images had to be dynamic

The filenames were all provided so this looks more complicated than it was but ... I ended up with this

const path = `${assetPath}/img/large/${buildingPath}`
const clad = `${path}cladding/amB${toTitleCase(building)}C_DR_${cladObj.file}.png`

For Local dev assetPath was '' for Prod it was roughly '/client/myapp/'

Bit crazy but it's a real world use case (perhaps a one off and not to worry about).

Creating import statements in such a case wouldn't make any sense.

In this case for prod I could easily add the domain and get it to work but locally I don't think that would work with Webpack dev server.

Wasn't sure if I should even bring this up as it's not a typical setup but figured I should at least mention such a case.

Something like a Photo Gallery might be a more typical use case.

gaearon · 2016-08-25T15:35:10Z

@timarney I sort of feel that for this use case you’re better off serving them from a local static server on a different port, and deploying them to a CDN in production.

timarney · 2016-08-25T15:39:00Z

@gaearon ya I think your right. It's really only a problem for local dev and it's fairly trivial to work around as you suggest.

eMerzh · 2016-09-03T12:26:53Z

i'm in the same kind of issue than @timarney , we have like sentry dns ... or api url or other config key that depend on the server / env. It would be cool to be able to "load" a and external js/json/something file to "configure" our app at run time.

gaearon · 2016-09-03T12:29:40Z

You have access to environment variables. This is documented in the usage guide in this repo. Does that help?

eMerzh · 2016-09-03T12:39:01Z

@gaearon yes I saw it... but it seems to help only for the dev version.. not for the builder one... Or I'm missing something?... I don't want those config variables into my compiled bundle... Because it change with every deployment

gaearon · 2016-09-03T13:05:47Z

Do you mean that you want to deploy the same build output to different servers, and making a separate build for each environment separately would be a pain?

eMerzh · 2016-09-03T14:43:03Z

Hum... Didn't think about that... might be possible but not really practical... And the tooling to make the multiple builds for dev/prod has to be made...
But wat if i want to distribute as compiled bundle but still with configurable parts...

PS: I totally understand and share your quest to keep it simple stupid and avoid any config. Just sharing my current workflow/issues

gaearon · 2016-09-03T14:55:28Z

You could post-process HTML for this like described here.

<head>
  <script>
    // $CONFIG
  </script>

You can replace // $CONFIG with something like window.CONFIG = { something: 42 } depending on environment before deployment, and you can have a fallback in your code if window.CONFIG doesn’t exist.

gaearon · 2016-09-03T19:05:54Z

I’m closing because I’m coming to the conclusion that this is either unnecessary or out of scope of CRA. Currently we give a strong guarantee that if a file changes, browser cache will be busted. We also give a single way to include images and other assets. I would prefer to keep it this way, and address other use cases on a case by case basis (e.g. #558).

gaearon · 2016-09-22T19:16:23Z

I drafted a proposal to solve this in #703. Unless we find some fatal flaws, it should come out in 0.5.0. Let me know what you think!

gaearon · 2016-09-23T21:56:34Z

This is now supported in 0.5.0.

Read about using the new public folder.

See also migration instructions and breaking changes in 0.5.0.

PrimeLens · 2017-05-03T13:46:48Z

Hi gaearon, I'm still looking for what you asked in the op which was the ability to bring a pre-minified javascript file into the bundle without it passing through webpack's minifier. Would it be possible to put this back on the to do agenda?

Edit: I do believe in the need for create-react-app as well as the need for alignment of general react ecosystem

PrimeLens · 2017-05-03T14:23:58Z

@gaearon

PrimeLens · 2017-05-03T14:54:58Z

Possible workarounds are to delay the firing of "ReactDOM.render of < App / > on #root until vendor files have loaded. This would mean include the vendor files in public, and linking to them in public/index.html and have them fire events off the window after each of them have loaded

gaearon · 2017-05-08T18:44:23Z

Hi gaearon, I'm still looking for what you asked in the op which was the ability to bring a pre-minified javascript file into the bundle without it passing through webpack's minifier. Would it be possible to put this back on the to do agenda?

Not into the bundle, but it's possible to put it into the public folder and load as a separate <script> tag. Does that help?

PrimeLens · 2017-05-08T19:07:25Z

Thats what I meant in the post just before your reply. It does mean figuring out a way to prevent the bundle from running before the other scripts have loaded

PrimeLens · 2017-05-08T19:12:19Z

Can also bring the script in and let it pass thru the web pack minification again and hope it is fine (it should be theoretically)

gaearon · 2017-05-08T19:13:45Z

The main bundle will always run last as far as I know. The bundle script is appended to the end of the document body.

PrimeLens · 2017-05-08T19:41:24Z

The calls are made asynchronously so bundle can start running before one of the earlier scripts has returned its called

gaearon · 2017-05-09T10:08:02Z

JS scripts wait for each other to execute. If your earlier script needs to do something async then you should export a global that lets the other script to wait:

// myscript.js
window.waitForThingsToHappen = function() {
  return fetch(/* ... */).then(/* whatever */);
}

// index.js
window.waitForThingsToHappen().then(() => {
  ReactDOM.render(<App />, root);
});

PrimeLens · 2017-05-09T13:19:10Z

Got it. Thanks @gaearon

gaearon added the future idea label Jul 20, 2016

gaearon mentioned this issue Jul 23, 2016

remove favicon.ico by default #108

Closed

gaearon added this to the 0.2.0 milestone Jul 25, 2016

dharmesh-khandelwal mentioned this issue Jul 26, 2016

How to include bootstrap? #201

Closed

mxstbr mentioned this issue Jul 26, 2016

Add support for a static folder #226

Closed

mxstbr added a commit that referenced this issue Jul 26, 2016

Add support for a static folder

fd41c2d

It is a nice escape hatch, ref: #28

gaearon removed this from the 0.2.0 milestone Jul 27, 2016

gaearon mentioned this issue Jul 29, 2016

Build fails when favicon is missing #291

Closed

mikaelbr mentioned this issue Aug 9, 2016

Adds png favicons to static folder as example #413

Closed

gaearon closed this as completed Sep 3, 2016

fson mentioned this issue Sep 5, 2016

Can't import image from src #585

Closed

Sep 6, 2016

Reference image in a markdown file #595

Closed

lock bot locked and limited conversation to collaborators Jan 21, 2019

"Vendor" folder #28

"Vendor" folder #28

Comments

gaearon commented Jul 19, 2016

gaearon commented Jul 19, 2016

frederikcreemers commented Jul 23, 2016

gaearon commented Jul 23, 2016

cliedeman commented Jul 23, 2016

gaearon commented Jul 23, 2016

ForbesLindesay commented Jul 25, 2016

gaearon commented Jul 25, 2016

baadc0de commented Jul 26, 2016

lacker commented Jul 26, 2016

hnordt commented Jul 26, 2016

mxstbr commented Jul 26, 2016

frederikcreemers commented Jul 26, 2016

Jul 26, 2016

timarney commented Aug 24, 2016

gaearon commented Aug 25, 2016

timarney commented Aug 25, 2016 • edited Loading

eMerzh commented Sep 3, 2016

gaearon commented Sep 3, 2016

eMerzh commented Sep 3, 2016

gaearon commented Sep 3, 2016

eMerzh commented Sep 3, 2016

gaearon commented Sep 3, 2016

gaearon commented Sep 3, 2016

gaearon commented Sep 22, 2016

gaearon commented Sep 23, 2016

PrimeLens commented May 3, 2017 • edited Loading

PrimeLens commented May 3, 2017

PrimeLens commented May 3, 2017 • edited Loading

gaearon commented May 8, 2017

PrimeLens commented May 8, 2017

PrimeLens commented May 8, 2017

gaearon commented May 8, 2017

PrimeLens commented May 8, 2017

gaearon commented May 9, 2017

PrimeLens commented May 9, 2017

timarney commented Aug 25, 2016 •

edited

Loading

PrimeLens commented May 3, 2017 •

edited

Loading

PrimeLens commented May 3, 2017 •

edited

Loading