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

Webpack devServer options ignored when using au run #794

Open
NightWulfe opened this issue Dec 8, 2017 · 6 comments
Open

Webpack devServer options ignored when using au run #794

NightWulfe opened this issue Dec 8, 2017 · 6 comments
Labels

Comments

@NightWulfe
Copy link

NightWulfe commented Dec 8, 2017

I'm submitting a feature request

Please tell us about your environment:

  • Operating System:
    Windows 10

  • Node Version:
    9.2.0

  • NPM Version:
    5.5.1

  • Browser:
    Firefox

  • Language:
    Typescript

  • Loader/bundler:
    Webpack

Current behavior:
Setting proxy, or other devServer configuration options, in webpack.config.json is ignored when using au run. This is because the run task (tasks/run.ts) creates its own options object and uses that.

  • What is the expected behavior?
    The devServer configuration from webpack.config.json options should be honored. My request is to move the opts configuration from run.ts into webpack.config.json, or at least merge the two configuration when run is invoked.

  • What is the motivation / use case for changing the behavior?
    Users familiar with webpack would be setting devServer options in webpack configuration file. Expecting that this would work, especially since the CLI places some devServer configuration options there, I spent an entire day troubleshooting why I couldn't get my proxy configuration to work. After some help from the gitter chat, I realized that the devServer options were being ignored entirely.

After looking at the run task (tasks/run.ts), I saw that it creates its own server options and completely ignores the options in webpack, using an opts object it creates in the task. After setting my proxy configuration there in run.ts, the proxy works fine.

@JeroenVinke JeroenVinke added the bug label Feb 2, 2018
@AshleyGrant
Copy link
Contributor

I'm not sure if this behavior should be changed. Users familiar with webpack will likely want to completely remove themselves from the aurelia cli environment, and so we might not want to give preference to options in that file.

What we might want to do, though, is look at moving the webpack config file in to the aurelia_project folder.

@Alexander-Taran
Copy link
Contributor

Alternative solution: a nice commented webpack.config.js file where it is clearly stated that options would be set via cli if used..
so the tinkering kind will know better.

@sirudog
Copy link

sirudog commented Oct 16, 2018

I agree with @NightWulfe. I just bumped into the same issue. Then I found this issue, so I went to check the aurelia docs here:
https://aurelia.io/docs/cli/basics#webpack-vs-built-in-bundler

This section especially suggests that if you need to customize your config, the webpack.config is the place to do that:
Webpack is a bundler with built-in module loader. If you choose to use Webpack then you don't need a separate module loader. Webpack is powerful and popular, but it could be a daunting task to set up Webpack from scratch. Aurelia CLI generates a battle-tested Webpack configuration file for your app, provides a solid base for further customization if you ever need to.

So if this behaviour will not be changed, at least the docs should be clear on when webpack-dev-server config is used/ignored.

@3cp
Copy link
Member

3cp commented Oct 16, 2018

Although I don't use webpack, I agree overwriting webpack config in run task is difficult for me to follow.

BTW, I wrote that newly updated piece of doc for webpack, without really understand the whole setup. The doc needs to be updated to describe how we control webpack config.

@ivanbacher
Copy link

Seems to be working now.

@3cp
Copy link
Member

3cp commented May 22, 2019

There is a fix #1088 merged but not released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants