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 for webpack.config returning array of configs #48

Open
1 task
ztalbot2000 opened this issue Dec 8, 2019 · 12 comments
Open
1 task

Support for webpack.config returning array of configs #48

ztalbot2000 opened this issue Dec 8, 2019 · 12 comments
Labels
enhancement New feature or request

Comments

@ztalbot2000
Copy link

  • I'd be willing to implement this feature
    I'd certainly be willing to test it with you on my current project.

Describe the user story
This is my first webpack project, but I think I have a good handle on it. It consists of a web app and a library as well. The web app will use the library, but it could be used in other projects. I had decided to split the two before I get too far down the road. I've chosen to write the project in typescript. As any good project has, there is built in unit testing via mocha.
my project builds in both dev and prod modes. To my surprise, It fails testing because the webpack.config returns an array of two webpack.Configuration types.
Now mocha pack is a front end to webpack test.js output.js && mocha output.js as you mention in your documentation. I learned that handling arrays can only be done when you import mocha-webpack-v2.0.0-beta.0; which sounds ominous ; but has been around for a year in alpha as Karma-webpack.rel6.

Now I come to the problem where mochapack does not handle arrays either, the last link in the chain, I believe.

The solution would be for mochapack to check if the webpack.Configuration returned is an array and then merge the content.

Describe the drawbacks of your solution
I have barely looked at your code, but believe merging would not cause any issues, the array of tests just grows based on the merge. you would know better.

This section is important not only to identify future issues, but also to see whether you thought your request through. When filling it, ask yourself "how can I break it".

mochapack would still have to detect that if an array was not given, to continue as normal.

Describe alternatives you've considered
I have tried separate config files, but this really has issues with watching for changes and now supporting two config files.

if push comes to shove, I will try to add it myself, but I'm sure you could do it faster.

thanks for the great tool.

John Talbot
[email protected]

@ztalbot2000 ztalbot2000 added the enhancement New feature or request label Dec 8, 2019
@larixer
Copy link
Member

larixer commented Dec 8, 2019

The solution would be for mochapack to check if the webpack.Configuration returned is an array and then merge the content.

I don't understand this solution. Why webpack configs should be "merged" by mochapack, why not by user, and how they should be merged exactly?

@Jack-Barry
Copy link

I'm curious, forgive me if I'm misreading the scenario - @ztalbot2000 are you describing a situation where you have multiple Webpack configurations and you want to run your test suite against each of them? You could do something like this in package.json:

"scripts": {
  "test": "mochapack", // You can add flags you want to use for all configs here
  "test:configA": "npm run test -- --webpackConfig path/to/configA.js",
  "test:configB": "npm run test -- --webpackConfig path/to/configB.js",
  "test:all": "npm run test:configA && npm run test:configB",
}

You could also use something like concurrently to speed things up and/or allow --watch mode in parallel:

"test:watch": "concurrently "npm run test:configA -- --watch" "npm run test:configB -- --watch"

I'm also curious what the design decision is to export an array of WebpackConfiguration objects instead of exporting them as their own entities? Would have to see your project to understand this better.

@ztalbot2000

This comment has been minimized.

@ztalbot2000
Copy link
Author

ztalbot2000 commented Dec 12, 2019 via email

@Jack-Barry

This comment has been minimized.

@ztalbot2000

This comment has been minimized.

@ztalbot2000

This comment has been minimized.

@ztalbot2000

This comment has been minimized.

@ztalbot2000

This comment has been minimized.

@Jack-Barry
Copy link

Jack-Barry commented Dec 12, 2019

@ztalbot2000 Here it is with syntax highlighted and irrelevant details removed. I am hiding your previous comments to keep this thread readable and to prevent an endless scroll.

const path = require('path');

module.exports = (env, argv) =>
{
   Externals = {};
   if ( argv && argv.mode && argv.mode == "production" )

   {
      // do production related things here
      // Hmm required for mocha but not for build ...
      console.log("Not bundling pixi.js");
      Externals= {"pixi.js": "PIXI"};
   } else {
      // do non-production related things here
      console.log("pixi.js will be bundled for testing");
   }

   // We have two entries. One for XXXXXXXXApp and the other for the library of  XXXXX-ui.
   // Note: you need my patch to fix mochapack handling arrays.
   return [  
      {
         entry: './app/src/XXXXXXXX-entry.ts',
         // other config details here
      },
      {
         entry: './app/src/XXXXXX-ui-entry.ts',
         // other config details here
      }
   ];
};

I'm still not thoroughly convinced the merging of config should be the responsibility of mochapack. There are some pretty lightweight alternatives to accomplishing this. You could have a production.webpack.config.js that does something like this:

import baseConfig from './webpack.config.js'

module.exports = (env, argv) => {
  return baseConfig(env, argv)[0]
}

and similarly handle the UI config. That way you can still inform mochapack of a file to use as config without giving up the reused setup of both configs.

@ztalbot2000
Copy link
Author

ztalbot2000 commented Dec 12, 2019 via email

@Timmmm
Copy link

Timmmm commented May 22, 2020

I believe they fixed that bug - webpack-dev-server serves both entries for me.

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

No branches or pull requests

4 participants