Custom additional webpack config?

[meghprkh]

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.

[goshacmd]

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]

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]

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]

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]

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.

[a-tarasyuk]

@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]

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]

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]

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]

@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]

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]

@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]

@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 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 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]

@gaearon Your patience is exemplary.

[jayarjo]

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

[kopax]

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

[Timer]

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

[kopax]

@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]

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]

@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 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.