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

Custom additional webpack config? #99

Closed
meghprkh opened this Issue Jul 22, 2016 · 23 comments

Comments

Projects
None yet
@meghprkh

meghprkh commented Jul 22, 2016

This would be helpful to set extra options to the config like publicPath and additional loaders as well as additional environment variables (I have a habit of using one for the public path).

One similar project, reactpack, that I used implemented this and I found it quite useful. They use webpack-merge if I am not wrong for merging the webpack configs.

@goshakkk

This comment has been minimized.

Contributor

goshakkk commented Jul 22, 2016

I think @gaearon has previously replied somewhere that allowing custom config, let alone one tied to webpack specifics, will limit CRA's ability to iterate on defaults and potentially use a different bundler under the hood

@eanplatter

This comment has been minimized.

Contributor

eanplatter commented Jul 22, 2016

We're trying to avoid having configuration in the API. The reason there is an eject script is so that if you get to a point where you need some deeper configuration you can eject CRA and access webpack directly.

@meghprkh

This comment has been minimized.

meghprkh commented Jul 22, 2016

well I guess you may know better but IMO you should provide the ability to tweak a few of the configs like public paths and environment variables. Speaking about environment variables reactpack allowed to have an .env.js file which had an exported JSON object whose keys were then used in webpack define plugin. This is useful for getting environment variables from process.env imo (I used to set publicPath as an env variable). Sorry if I am referencing reactpack too much but thats the only ready-to-use-config tool I used.

Close this if you wish please

@gaearon

This comment has been minimized.

Member

gaearon commented Jul 22, 2016

We don't intend to provide Webpack specific overrides because it will be very fragile. People will start depending on specific loaders and plugins and we won't be able to improve the overall experience.

We would like to encourage you to file issues about specific pain points you encountered. We understand you want to configure some things. Please help us understand what these things are, and why you want to configure them. We will look at those requests holistically and perhaps find another solutions, or maybe introduce some minimal configuration.

@gaearon gaearon closed this Jul 22, 2016

@gaearon

This comment has been minimized.

Member

gaearon commented Jul 22, 2016

You can look at #21 and #85 for examples of this approach. These things could have been configuration flags but perhaps we can make a good enough system with some reasonable heuristics. This is how we'd like to solve such problems so please keep them coming.

@gaearon gaearon referenced this issue Jul 22, 2016

Closed

General feedback #11

@a-tarasyuk

This comment has been minimized.

a-tarasyuk commented Jul 22, 2016

@gaearon ok, for instance I have one project where I need <some useful plugin> and second project works better without it, how can I solve this issue? In my opinion, we can't predict all scenarios, so that's why I suggest have opportunity extend default configs. Does it make sense?

@gaearon

This comment has been minimized.

Member

gaearon commented Jul 22, 2016

Not sure I understand your point about gzip compression. It would be applied on the server anyway, right? So this shouldn't affect how you compile your assets.

If you have other specific examples I am happy to discuss them in specific issues.

@a-tarasyuk

This comment has been minimized.

a-tarasyuk commented Jul 22, 2016

My point is that in some cases we need opportunity add/remove loaders/plugins., how can I add some plugin which my project needs, and this plugin does not exists in create-react-app? I propose add config folder/file where users can manage wepback/eslint and so on.

/config
  - webpack.js
     { 
       development: { loaders: [], plugins: [] },
       production: { loaders: [], plugins: [] },
    }

or config.js where there is section for each of tools which there are in create-react-app

  {
     webpack: {...},
     eslint: {}
     ...
  }

I don't say that we should have full webpack control, however minimal impact on it we should have, at least we should have opportunity manage plugins, and loaders... Does it make sense?

@gaearon

This comment has been minimized.

Member

gaearon commented Jul 22, 2016

As I said above we don't plan to provide any Webpack specific configuration. If you'd like to configure loaders or plugins, you are probably better served by other projects. You can find a big list of alternatives at the end of the README, and some of them support that.

However we are happy to discuss specific use cases. For example, rather than "I needed to configure loaders" you could say "I needed SASS" or "I wanted to deploy my app at different paths", etc. This way we can keep those use cases in mind while planning future work.

@a-tarasyuk

This comment has been minimized.

a-tarasyuk commented Jul 22, 2016

@gaearon What about specific options for loaders and plugins? How can I enable/disable options, for instance for UglifyJsPlugin? For example I need quickly enable/disable beautify option, how can I do it?

@gaearon

This comment has been minimized.

Member

gaearon commented Jul 23, 2016

If we make everything configurable, this tool will become another webpack. If you’re comfortable doing this, you can use eject and tweak the options at any time.

For example I need quickly enable/disable beautify option, how can I do it?

Can you please describe the use case? i.e. not what you want to tweak but why. Why do you need to tweak that option? What other options do you often tweak?

@CodeJjang

This comment has been minimized.

CodeJjang commented Sep 21, 2016

@gaearon For example wanting to load bootstrap css in a specific order (before all other stylesheets are loaded so UI won't be messed up).
This is such a simple thing to ask and there's no reason to eject or to switch kit for this reason.
I think you have exaggerated a bit with the 'don't tweak our configurations' thing, because every kit needs to be configurable a bit.

@gaearon

This comment has been minimized.

Member

gaearon commented Sep 22, 2016

@CodeJjang

Please file an issue about this use case and let's discuss it specifically. I'm happy to see specific use cases so we can look at ways of addressing them. In my experience there are often other ways of solving the same issues than adding configuration.

@nylen

This comment has been minimized.

nylen commented Nov 17, 2016

This is possible to achieve today, though definitely unsupported. Automattic/wp-api-console#45 (comment) is an example for a production build, and it looks like something similar would work for the dev server too.

@gaearon

This comment has been minimized.

Member

gaearon commented Nov 20, 2016

This is exactly the case where instead of / in addition to reaching into internals it would be appropriate to file an issue describing the use case. I'd be happy to add Lodash plugin by default.

If you add hacks please also start a dialogue. This way both your setup is more future proof and users can benefit from better defaults. Thanks!

@jgwconsulting

This comment has been minimized.

jgwconsulting commented Mar 1, 2017

@gaearon Your patience is exemplary.

@jayarjo

This comment has been minimized.

jayarjo commented Mar 3, 2018

Is it possible to somehow use absolute paths when importing modules, instead of relative, without ejecting?

@kopax

This comment has been minimized.

kopax commented Mar 21, 2018

Hi @gaearon, How can I use https://www.npmjs.com/package/react-svg-loader ? Do I need to eject?

@Timer

This comment has been minimized.

Collaborator

Timer commented Mar 26, 2018

SVG support was added in react-scripts 2.0. Please see the release announcement in the issue tracker.

@kopax

This comment has been minimized.

kopax commented Mar 26, 2018

@Timer is it like react-svg-loader wrapping your svg in a react component are is it the very simple and img tag dumbly linked to svg using it's src attribute?

@iansu

This comment has been minimized.

Collaborator

iansu commented Mar 26, 2018

You can do both.

// gives you the URL
import logo from './logo.svg';

//gives you a React component <Logo />
import { ReactComponent as Logo } from './logo.svg';
@kopax

This comment has been minimized.

kopax commented Mar 26, 2018

@iansu it does not.

// gives you undefined
import { ReactComponent as Logo } from './logo.svg';

I have just tested with :

  • react: 16.2.0
  • react-dom: 16.2.0
  • react-scripts: 1.1.1
@iansu

This comment has been minimized.

Collaborator

iansu commented Mar 26, 2018

This feature exists in the react-scripts 2.0 alpha version. You can find instructions on installing it here: #3815

Please don't comment on old, closed issues. If you continue to have problems create a new issue.

@facebook facebook locked and limited conversation to collaborators Mar 27, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.