Q:

webpack split chunks put everything in one file

I have large application, and I want split it.
Currently I have this structure:
application.js < entry point
Messages.js < application.js inner module
SystemSetup.js < application.js inner module
/node_modules/react.js < node modules
Common.js < local file, used inside of Messages and SystemSetup

Is it possible to split it into same chunks? I mean, I need to get 
Common.js < module(chunk) with no dependencies
node_module.js < module(chunk) without dependencies
Messages.js < depends from Common and node_modules
SystemSetup.js < depends from Common and node_modules
application.js < depends from Messages and SystemSetup

Currently I made this webpack config file:
const path = require('path');
const WebpackNotifierPlugin = require('webpack-notifier');
const AsyncChunkNames = require('webpack-async-chunk-names-plugin');
const Profile = require('./src/js/Profile');
const production = Profile.environment === 'prod';

module.exports = {
    mode: production ? 'production' : 'development',
    entry: {
        application: './src/js/Application.js',
        Messages: './src/js/components/routes/Messages.js',
        SystemSetup: './src/js/components/routes/SystemSetup.js'
    },
    output: {
        path: path.resolve(__dirname, '../assets/js/'),
        filename: '[name].js',
        chunkFilename: '[name].js',
        publicPath: "/"
    },
    cache: true,
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: ['babel-loader']
            }
        ]
    },
    watchOptions: {
        ignored: /node_modules/
    },
    plugins: [
        new WebpackNotifierPlugin({alwaysNotify: true, title: 'Webpack JS job'}),
        new AsyncChunkNames()
    ],
    devtool: 'source-map',
    resolve: {
        alias: {
            root: path.join(__dirname, 'src/js/'),
            '~': path.resolve(__dirname, 'src/js/'),
        }
    },
    optimization: {
        splitChunks: production ? {} : {
            cacheGroups: {
                default: false,
                vendors: false,
                node_modules: {
                    name: 'node_modules',
                    chunks: 'all',
                    test: /node_modules/,
                    priority: 40
                },
                common: {
                    name: 'common',
                    minChunks: 2,
                    chunks: 'all',
                    priority: 20,
                    reuseExistingChunk: true,
                    enforce: true
                },
                Messages: {
                    name: 'Messages',
                    chunks: 'all',
                    test: /.*\/Messages\.js$/,
                    reuseExistingChunk: true,
                    priority: 30
                },
                SystemSetup: {
                    name: 'SystemSetup',
                    chunks: 'all',
                    test: /.*\/SystemSetup\.js$/,
                    reuseExistingChunk: true,
                    priority: 30
                },
            }
        }
    }
};

I got all bundles - But result is not good. I have such files:
Common.js < 11mb files, expected around 5mb
node_module.js < 3.7 mb < looks good
Messages.js < 7kb, expected around 3mb
SystemSetup.js < 7kb, expected around 3mb
application.js < 7kb < looks good

A:

First of all, let me clear this about using modern approach for Javascript bundling with Webpack using ES6 modules [ES2015].

The most important difference between the current JS Module formats (CommonJS, AMD) and ES6 modules is that ES6 modules are designed with static analysis in mind.
This means that when you import modules, the import is resolved at compile time  that is, before the script starts executing. 
This allows us to remove exports that are not used by other modules before we run the program.
Removing unused exports can lead to significant space savings, reducing stress on the browser.

How is this any different from the dead code elimination that happens when you use something like UglifyJS to minify your code?
The answer is, it depends. Dead code elimination is an optimization step which removes unused code and variables   think of it as removing the excess baggage that your bundled program doesn’t need to run, after it’s been bundled.
Sometimes, dead code elimination could work exactly the same between UglifyJS and ES6 modules, and other times not.
A Modern approach for JavaScript bundling with Webpack
Webpack is a modern static file bundling tool. In case of JavaScript file bundling it helps to eliminate the implicit dependency on sorted  tags in our markup. Instead of including many separate scripts we include single or few bundles using the same  tag.
To do so we should first create those bundles. And to create bundle we need to configure Webpack. Of course Webpack should be installed on the machine for example by command npm install webpack --save-dev.
In it's bare minimum all that Webpack needs is an entry point and output. It can then be called simply by executing command.
./node_modules/.bin/webpack app/entry.js dist/output.js

In this case Webpack will load entry.js and will look up for import or require keywords within it to determine whether it should load more dependencies. If dependencies are found it will load them recursively and also include them in the output file
JavaScript modules
As noted in previous section the script file can include dependencies referenced by import or require.
// CommonJS
require ('lodash')
console.log(_);
// ECMA6
import 'lodash'
console.log(_);
// Notice currently you need to transpile ECMA6 import using for example Babel to make it run in browsers

This is just to point the fact that one can use the feature of referencing dependencies within a JavaScript file. With default Webpack configs it will bundle an output script which won’t be compatible with current browsers. And as noted in the comments we need to process the script files containing imports or requires. This can be done using Babel JavaScript transformer whose task is to take JavaScript written in ECMA6 and translate it to working ECMA5 JavaScript. You can find more about JavaScript import and export on Mozilla Developer Network.
Bundling JavaScript The Webpack way
You can bundle your JavaScript using the CLI command by providing an entry file and output path. Webpack will automatically resolve all dependencies from import and require. And bundle them into single output together with your app’s script.
But that’s just the bare minimum it can do. To extend the functionality we can create a Webpack’s config file and configure various tasks the bundler performs when processing JavaScript.
Configuration
First we need to create a webpack.config.js file and require webpack from node_modules.
// webpack.config.js
var webpack = require('webpack');
module.exports = {
    entry: {
        entry: __dirname + '/entry.js'
    },
    output: {
        filename: '[name].bundle.js'
    }
}

Here we have provided the entry file as entry.js and prefixed the path of current directory where Webpack is executed. Also provided the output path where to put the content of bundled JavaScript. Note the [name] prefix of the file. This instructs Webpack to concatenate the entry file name with .bundle.js ending. Now by executing a CLI command.
./node_modules/.bin/webpack

it will create an entry.bundle.js file in the current module’s directory.
Loaders
As I wrote earlier if you use import to reference JavaScript dependencies in your script you have to transpile it from ECMA6 to ECMA5 script using Babel. Webpack can do this on the fly by utilizing it’s loaders feature. To make it work we must first install necessary node modules npm install babel-core babel-loader babel-preset-es2015 and update webpack.config.js with modules section.
// webpack.config.js
var webpack = require('webpack')
module.exports = {
    entry: {
        entry: __dirname + '/entry.js'
    },
    output: {
        filename: '[name].bundle.js'
    },
    module: {
        loaders: [
            {
                test: /\.js$/,
                loader: 'babel-loader',
                exclude: /node_modules/,
                query: {
                    presets: ['es2015']
                }
            }
        ]
    },
}

In modules section we can set many loaders which are applied to JavaScript at processing time. Notice we have set that all files ending with *.js, excluding node_modules, should be processed through babel-loader. Thus it will generate ECMA5 compatible code as output. So now if we would add for example a dependency to helloWorld.js in the entry.js the Webpack would be able to generate working code.
// helloWorld.js
export const helloWorld = 'Hello world from imported JS!';
// entry.js
import {helloWorld} from './helloWorld'
console.log(helloWorld); // Will print 'Hello world from imported JS!' in browser's console

Plugins
So we have seen the entry, output and modules configuration in action. But there is one more section for base configuration which is worth look at. It’s plugins. Simply said a plugin is the same to bundled JavaScript as loader is to a single JavaScript dependency. Plugins allow us to perform a various tasks on bundles. For example extracting duplicate code chunks into separate files or uglify the output.
// webpack.config.js
var webpack = require('webpack')
module.exports = {
    entry: {
        entry: __dirname + '/entry.js'
    },
    output: {
        filename: '[name].bundle.js'
    },
    module: {
        loaders: [
            {
                test: /\.js$/,
                loader: 'babel-loader',
                exclude: /node_modules/,
                query: {
                    presets: ['es2015']
                }
            }
        ]
    },
    plugins: [
        new webpack.optimize.UglifyJsPlugin()
    ]
}

As you can see we have added a new section to the Webpack config plugins. It can contain many plugins to be executed on the bundled JavaScript. By itself Webpack provide a list of useful plugins. But you can also build your own for your specific reasons.
Pros

More control over dependencies as view imports only scripts it needs to work.
Usage of modern JavaScript (ES6 features).
Webpack can analyze the content of JavaScript on compile time. Thus providing more info for optimization.
Referencing classes is similar like doing it in C# or PHP.

Cons

A need to install an extra tool when there exists a feature in framework.
Developer must define all entry points (one per page or view) in configuration.
JavaScript must be modular both application's and 3rd party's.

(OR)
If you want only to split your chunks with webpack: The 100% correct way to split your chunks with Webpack

