Static asset in-lining

[Timer]

When 0.10 is released (with #1305), I have a feeling we'll be seeing a lot more of issues like #1938.

These users have a perfectly legitimate use case and I believe we should handle it.
They desire to require a text file, or other types (e.g. markdown, other markup), and receive raw data. There was also a recent issue asking to require JS as text and not processed as a module.

There are many imaginable use cases for this, and have been a huge amount of issues we've responded to with a

put it in a export default '';

To remedy this, I believe we should in-line assets via fs.readFileSync(...), similar (identical) to brfs.
This would allow users to require any arbitrary file as UTF8 text or a Buffer.

[viankakrisna]

hurray for something like brfs! brfs have some issues though if we want to implement it using transform-loader webpack-contrib/transform-loader#3 do you eye-ing for something else?

[gaearon]

Would love to see a proof of concept.

[viankakrisna]

Possible solutions:

1. adding a raw-loader for *.inline.* / *.raw.* suffix, just like how CSS modules PR (do we even want to go ahead with this suffix thing?)
2. babel-macros with babel-plugin-preval -> need to see it mature first?

[viankakrisna]

3. Leave the current behavior, document using fetch with file-loader / public folder / export template string instead.

[cdaringe]

i really want this, but i'm not sure how to do it effectively. i see a few options:

• we expose the loader, or at least passively permit people to raw!./thing
  • fear not @gaearon, i assume thats a 👎 😉
• some file naming convention
• leverage the env
  • REACT_APP_RAW=csv,of,files,or,glob

i'm liking the 3rd option. thoughts?

[Timer]

What's wrong with using fs.readFileSync? That's convention in the browserify world.

[cdaringe]

i suppose we could do that, @Timer, it just feels a little funky to not use webpack for the single source of asset aggregation. even tho i love node, seeing fs in UI code looks a little wonky, but who knows, maybe that's a good visual trigger! under the same logic about "we shouldn't expose the build system" to the user, maybe not exposing the build system's runtime falls under the same argument?

i'm not powerfully swayed one way or the other, but continuing to use webpack + an ENV var feels like it may render less friction

[jkschneider]

While debate continues on this, you can use raw-loader today without ejecting or forking with:

/* eslint import/no-webpack-loader-syntax: off */
import QuickStart from '!raw-loader!./Sections/QuickStart.md';

The leading ! is important, as otherwise all but a defined set of excluded extensions will get loaded by file-loader instead.

I know this isn't recommended, but I find an explicit binding to Webpack to be more palatable than eject or forking. Feels like a tradeoff between trouble caused by some hypothetical future state where CRA no longer uses Webpack and trouble now maintaining my fork or falling behind on updates to key pieces of the setup.

[Timer]

@jkschneider be aware that we might break this in the future. It's not permitted behavior.

[gaearon]

Related: #3722.

[johnflux]

Note that the !raw-loader! approach breaks the jest tests.

[Timer]

Closing in favor of above linked issue.