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

Support setting the config name for multiple configs #1657

Closed
1 of 2 tasks
DBosley opened this issue Jul 6, 2018 · 26 comments · Fixed by #1753
Closed
1 of 2 tasks

Support setting the config name for multiple configs #1657

DBosley opened this issue Jul 6, 2018 · 26 comments · Fixed by #1753
Projects

Comments

@DBosley
Copy link

DBosley commented Jul 6, 2018

Operating System: Ubuntu 18.04
Node Version: 8.11.1
NPM Version: 6.0.0
webpack Version: 4.12.0
webpack-hot-client Version: 4.0.3

  • This is a feature request
  • This is a bug

What is the motivation and/or use-case for the feature?

Webpack supports multiple configurations in a single file by exporting an array.
Info Here
A new feature that was added recently (but currently lacks total documentation) is that you can set a 'name' property in your webpack config and pass --config-name to the cli to choose a specific config to build if you don't want to build all of them.

This feature request is to allow support of this functionality in the webpack-dev-middleware and related plugins.

Implementing this could be done in a couple ways:

  • Support passing webpack-cli options into the middleware somehow
  • Support choosing a config-name in the middleware options

I think the first solution is going to be the best approach if it's possible. This is because it would allow any webpack-cli arguments to be used with middlewares. If for some reason there's no way to go down this route, the second option would suffice for my use case, but it might be a good idea to look at other options listed here to see if they would merit being included as well

@shellscape

This comment has been minimized.

@DBosley
Copy link
Author

DBosley commented Jul 6, 2018

This issue arose while using webpack-serve and the way I envisioned the end-result of the implementation would be to pass the cli arguments in when running webpack-serve in the cli. Somehow allowing these to pass them through to whatever webpack-cli you're using behind the scenes. At the same time, I assume webpack-serve and webpack-dev-middleware might not be using any sort of webpack-cli under the hood at all, instead opting to use the webpack API, which is the reason I suggested the two approaches.

If either webpack-command or webpack-cli are actually being called in the middleware, passing whatever arguments through sounds fairly trivial. But if you're only using the API, it makes perfect sense to target specific use cases.

@shellscape
Copy link

Yeah take a quick peek at package.json and that'll tell you if a CLI is being used under the hood 😉

The webpack-serve CLI use-case is interesting. In that situation, you'd first need support for a configName option in this repo, and then request that webpack-serve support a --config-name flag.

@evenstensberg
Copy link
Member

@shellscape This would align well in a separate repo that has a options file that both serve and cli can use. The feature wouldn't be hard to implement. Import the file and object assign on the file

@shellscape
Copy link

@ev1stensberg what? no. that would be a horrible architectural decision.

@evenstensberg
Copy link
Member

Perhaps, but it's better than directly importing the config and depending on that. A hard copy in Dev server would make it harder to maintain features if/when they are removed, added or modified

@shellscape
Copy link

shellscape commented Jul 7, 2018

@ev1stensberg I don't think you understand the conversation here. No one is talking about importing configs.

@DBosley I'll see about getting into this next week. It may not look exactly like the suggestions you had, but pretty sure I know how we can make this happen.

@evenstensberg
Copy link
Member

I do, config -> yargs config. Makes it possible for us to bridge the libraries better. But seems like you got this under control.

@michael-ciniawsky michael-ciniawsky changed the title Support webpack-cli options and/or webpack multiple configuration export [Feature] Support setting the config name for multiple configs Aug 23, 2018
@michael-ciniawsky michael-ciniawsky changed the title [Feature] Support setting the config name for multiple configs Support setting the config name for multiple configs Aug 25, 2018
@alexander-akait
Copy link
Member

@DBosley can you provide example how you can see this implementation?

@hinell
Copy link

hinell commented Feb 15, 2019

Probably a bit late to party.
There are typically always two types of servers: development and production ones.
In both you can specify which config to use by simply importing it and referencing it.

@eragon512
Copy link

eragon512 commented May 19, 2019

hey, I'm a new contributor and I'd like to take up this issue, is it available/active?

@alexander-akait
Copy link
Member

Yes, PR welcome

@EslamHiko
Copy link
Member

@evilebottnawi I have a suggestion we can create 2 options one is configs or configPath its value will be the path to a config file ex:webpack.middleware.js or an array with a group of options with mode value. and we have the second option will be mode which if it's set it'll import the options from the group of options. so what do you think?

@alexander-akait
Copy link
Member

@EslamHiko this issue about supporting name as argument for build, webpack configuration can has multiple configuration (example https://github.com/webpack/webpack/tree/master/examples/multi-compiler), you developer provide this option we should compile only configuration with provided name

@alexander-akait alexander-akait transferred this issue from webpack/webpack-dev-middleware Jun 30, 2020
@webpack-bot
Copy link

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

@alexander-akait
Copy link
Member

We need implement the name flag to run one/two/more of multiple compilers, also it can be --name=web --name=server (multiple args)

/cc @webpack/cli-team

@snitin315
Copy link
Member

@evilebottnawi multiple compilers simultaneously?

@alexander-akait
Copy link
Member

alexander-akait commented Jun 30, 2020

Yes. With --name=web - run compiler with web name. Should be easy, just filter configuration and remove compiler with web name, same for multiple values

@snitin315 snitin315 added this to To do in GSoC 2021 Jul 1, 2020
@rishabh3112
Copy link
Member

@snitin315 a heads up, the name flag will also be underwork #1649, I suggest to start working on this (if needed) after that PR gets merged to avoid duplicate work :)

@snitin315
Copy link
Member

makes sense 👍

@snitin315
Copy link
Member

Yes. With --name=web - run compiler with web name. Should be easy, just filter configuration and remove compiler with web name, same for multiple values

@evilebottnawi Now we support --name=web(which runs compiler with web name) for webpack@next, but it can't accept multiple values.
https://github.com/webpack/webpack/blob/a3bef27457d8936f81525beaa633eb1931382dc0/test/__snapshots__/Cli.test.js.snap#L1099

@alexander-akait
Copy link
Member

@snitin315 Let's improve it

@snitin315
Copy link
Member

We should improve it at the core or here (in CLI)?

@alexander-akait
Copy link
Member

CLI, it is out of scope core

@snitin315
Copy link
Member

--name=web flag purpose is set options.name = 'web'. To implement the ability to choose between multiple configs we should implement a different flag --config-name for example like done in v3.

@alexander-akait
Copy link
Member

Yes, you are right

@snitin315 snitin315 moved this from To do to In progress in GSoC 2021 Aug 18, 2020
GSoC 2021 automation moved this from In progress to Done (Phase 3) Aug 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
GSoC 2021
  
Done (Phase 3)
Development

Successfully merging a pull request may close this issue.

10 participants