-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
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? |
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 "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 "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 |
This comment has been minimized.
This comment has been minimized.
As you mentioned, I can split the two tasks in my package.json script tag,
but as I spent so much time getting it into one, I needed to continue. I'm
sure that if not me, eventually you will be asked anyway. For now, I'll use
my patch. if I'm ready to publish, I can always separate them. at least
then it would be easy.
ttfn,
John
…On Thu, Dec 12, 2019 at 8:24 AM John Talbot ***@***.***> wrote:
this is my Webpack-config file. I had to blur out some names as while
this will be an open-source project (As is all my others) it is not even
close to being unveiled. it will eventually be, but not know. As I figure
thing out, I comment it to death, but you can see the array.
const path = require('path');
const UglifyJsPlugin = require('uglifyjs-webpack-plugin');
const HtmlWebpackPlugin = require('html-webpack-plugin');
module.exports = (env, argv) =>
{
Externals = {};
//if (argv && argv.mode && argv.mode ="production")
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");
}
return [ // 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.
{
entry: './app/src/XXXXXXXX-entry.ts',
output: {
path: path.resolve(__dirname, './dist'),
filename: 'XXXXXXXXApp.js',
/// At this time the Grid class is the only thing that works
// and since it extends Sprite, it cannot be a Library.
// XXXXX-ui would be a library and it will be created as such
// with another entry point. so for now, leave these commented
out.
// The library name means you would access it via
XXXXXXXX.Grid.
//library: 'XXXXXXXX',
//libraryTarget: 'umd',
//umdNamedDefine: true
},
// For when --watch is specified, automatically compile ...
watchOptions: {
// Add a delay before rebuilding once the first file changed.
aggregateTimeout: 1000,
// Check for changes every 3 seconds
poll: 3000,
ignored: ['app/uitry',
'test/uitry',
/node_modules/
]
},
devServer: {
// Tell the server where to serve content from (Static files
only).
// It is recommended to use an absolute path.
contentBase: path.join(__dirname, 'dist'),
// The bundled files will be available in the browser under
this path.
// Make sure devServer.publicPath always starts and ends with
a forward slash.
publicPath: '/dist/',
// The filename that is considered the index file.
index: 'XXXXXXXX.html',
// Enable gzip compression for everything served:
compress: false,
// Specify a port number to listen for requests on.
port: 9000,
// Enables/Disables colors on the console
// Available on cli only --color
// color: true,
// Tell dev-server to watch the files served by the
devServer.contentBase option.
// It is disabled by default. When enabled, file changes will
trigger a full page reload.
watchContentBase: true,
// Control options related to watching the files.
// webpack uses the file system to get notified of file
changes.
// In some cases this does not work.
// In these cases, use polling:
watchOptions: {
// Set to 5 seconds
poll: 5000
},
// By default, the dev-server will reload/refresh the page
when file changes are detected.
// devServer.hot option must be disabled or
devServer.watchContentBase option must be enabled
// in order for liveReload to take effect.
liveReload: true,
// Enable webpack's Hot Module Replacement feature:
// Note: requires a lot of other stuff too in index.html ...
hot: false,
onListening: function(server) {
const port = server.listeningApp.address().port;
console.log('Listening on port:', port);
},
// Tells dev-server to open the browser after server had been
started.
open: true,
// Specify a page to navigate to when opening the browser.
openPage: 'XXXXXXXX.html'
},
plugins: [
// The plugin will generate an HTML5 file for you that includes
// all your webpack bundles in the body using script tags.
new HtmlWebpackPlugin({
// The file to write the HTML to. Defaults to index.html.
// It will be placed in path: above. You can add further
// subdirectories if need be
filename: 'XXXXXXXX.html',
// The title to use in the generated HTML document
title: 'XXXXXXXX',
// Instead of the default template that would be created
// Use ours.
template: 'app/src/XXXXXXXX.html.template',
// Allows to overwrite the parameters used in the template
// templateParameters: {Boolean|Pbjects|Function}
// Inject all assets of template at position
// inject: true || 'head' || 'body' || false
inject: 'body',
// Adds the given favicon path to the output HTML
// When you touch the URL you will see the bunny
favicon: 'bunny.png',
// Inject the following meta tags
meta: {
VIEWPORT: 'WIDTH=device-width, INITIAL-SCALE=1,
SHRINK-TO-FIT=no'
},
// Inject a base tag.
// E.g. base: "https://example.com/path/page.html
base: 'http://localhost/~zarf',
// Controls if and in what ways the output should be
minified.
// Default is only true for production mode
minify: false,
// Emit the file only if it was changed. Default is true.
cache: true,
// Errors details will be written into the HTML page.
// Default is true.
showErrors: true,
// Allows you to add only some chunks (See docs)
// (e.g only the unit-test chunks)
// chunks:
// chunksSortMode:
// excludeChunks:
// true render the link tags as self-closing (XHTML
compliant)
xhtml: false
})
],
target: 'web',
externals: Externals,
resolve: {
// Add '.ts' as resolvable extensions.
extensions: [".ts", ".js"],
alias: {
$: "jquery/src/jquery",
}
},
optimization: {
minimizer: [
new UglifyJsPlugin({
parallel: true,
uglifyOptions: {
mangle: false
}
})
]
},
// Seperate source maps
devtool: "source-map",
module: {
rules: [
{
test: /\.js$/,
include: [path.resolve(__dirname, "app")],
exclude: [
// This would be a regular expression
/node_modules/,
// This would be a path
// Omit stuff to be worked on
'/app/ui/', // We are doing XXXXXXXX so omit
UI
'/test/ui', // We are doing XXXXXXXX so omit
UI
'/app/uitry/', // Omit all uitry
'/test/uitry' // Omit all uitry
],
use: {
loader: 'babel-loader'
// Note. Do not put options here !!!
// ts-loader or babel-loader may override them.
// i.e ts-loader listFiles: true or
// ts-loader outdir: 'js'
}
},
{
test: /\.ts$/,
include: [path.resolve(__dirname, "app")],
exclude: [
// This would be a regular expression
/node_modules/,
// This would be a path
// Omit stuff to be worked on
'/app/ui/', // We are doing XXXXXXXX so omit
UI
'/test/ui', // We are doing XXXXXXXX so omit
Ui
'/app/uitry/', // Omit all uitry
'/test/uitry' // Omit all uitry
],
use: {
loader: "ts-loader"
// Note. Do not put options here !!!
// ts-loader or babel-loader may override them.
// i.e ts-loader listFiles: true or
// ts-loader outdir: 'js'
}
}
]
},
},
{
entry: './app/src/XXXXXX-ui-entry.ts',
output: {
path: path.resolve(__dirname, './dist'),
filename: 'XXXXXX-ui.js',
library: 'XXXXXX-ui',
libraryTarget: 'umd'
},
plugins: [
],
target: 'web',
externals: Externals,
resolve: {
// Add '.ts' as resolvable extensions.
extensions: [".ts", ".js"],
alias: {
$: "jquery/src/jquery",
}
},
optimization: {
minimize: false,
},
// Enable sourcemaps for debugging webpack's output.
// // devtool: "source-map" // without any, there is no sourcemap
//devtool: "eval" // none
devtool: "source-map" // one big blob
//devtool: "eval-source-map" // none
module:
{
rules: [
{
test: /\.js$/,
include: [path.resolve(__dirname, "app")],
exclude: [
// This would be a regular expression
/node_modules/,
// This would be a path
// Omit stuff to be worked on
'/app/XXXXXXXX', // We are doing UI so omit
XXXXXXXX
'/test/XXXXXXXX', // We are doing UI so omit
XXXXXXXX
'/app/uitry', // Omit all uitry
'/test/uitry/' // Omit all uitry
],
use: {
loader: 'babel-loader',
// Note. Do not put options here !!!
// ts-loader or babel-loader may override them.
// i.e ts-loader listFiles: true or
// ts-loader outdir: 'js'
}
}
},
{
test: /\.ts$/,
include: [path.resolve(__dirname, "app")],
exclude: [
// This would be a regular expression
/node_modules/,
// This would be a path
// Omit stuff to be worked on
'/app/XXXXXXXX', // We are doing UI so omit
XXXXXXXX
'/test/XXXXXXXX', // We are doing UI so omit
XXXXXXXX
'/app/uitry', // Omit all uitry
'/test/uitry/' // Omit all uitry
],
use: {
loader: "ts-loader"
// Note. Do not put options here !!!
// ts-loader or babel-loader may override them.
// i.e ts-loader listFiles: true or
// ts-loader outdir: 'js'
}
}
}
]
},
}
];
};
On Thu, Dec 12, 2019 at 8:03 AM Jack Alden Barry ***@***.***>
wrote:
> I'm curious, forgive me if I'm misreading the scenario - @ztalbot2000
> <https://github.com/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
> <https://github.com/kimmobrunfeldt/concurrently#readme> 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.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#48?email_source=notifications&email_token=ABSBCX2MN3BA7SMIQX7QJ63QYIZDTA5CNFSM4JX4WEBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGWTAMQ#issuecomment-564998194>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABSBCX66QUHXR4Q5LX23UC3QYIZDTANCNFSM4JX4WEBA>
> .
>
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@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 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 |
Just to let you know, I have determined that Webpack-devserver only acts on
the first entry, but at least it does not bail. So there is at least
precedence for handling it this way.
TTFN,
John
…On Thu, Dec 12, 2019 at 10:48 AM Jack Alden Barry ***@***.***> wrote:
@ztalbot2000 <https://github.com/ztalbot2000> Here it is with syntax
highlighted and irrelevant details removed. I am deleting 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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48?email_source=notifications&email_token=ABSBCX5AALTOFIHLLN33VH3QYJML5A5CNFSM4JX4WEBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGXC7NI#issuecomment-565063605>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABSBCXYG5YFUKYGNGZ3I4ZDQYJML5ANCNFSM4JX4WEBA>
.
|
I believe they fixed that bug - |
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]
The text was updated successfully, but these errors were encountered: