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

Static asset in-lining #1944

Closed
Timer opened this Issue Apr 7, 2017 · 12 comments

Comments

Projects
None yet
6 participants
@Timer
Copy link
Collaborator

commented Apr 7, 2017

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.

@Timer Timer added this to the 0.10.0 milestone Apr 7, 2017

@viankakrisna

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2017

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?

@Timer Timer referenced this issue May 5, 2017

Closed

1.0.0 Roadmap #2089

12 of 32 tasks complete

@gaearon gaearon modified the milestones: 0.11.0, 0.10.0 May 16, 2017

@gaearon

This comment has been minimized.

Copy link
Member

commented May 16, 2017

Would love to see a proof of concept.

@viankakrisna

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2017

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

This comment has been minimized.

Copy link

commented Jul 15, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 15, 2017

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

@cdaringe

This comment has been minimized.

Copy link

commented Jul 18, 2017

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

This comment has been minimized.

Copy link

commented Jul 18, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 18, 2017

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

@gaearon

This comment has been minimized.

Copy link
Member

commented Jan 9, 2018

Related: #3722.

@johnflux

This comment has been minimized.

Copy link

commented Apr 25, 2018

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

@Timer

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 1, 2018

Closing in favor of above linked issue.

@Timer Timer closed this Jun 1, 2018

@lock lock bot locked and limited conversation to collaborators Jan 19, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.