Large Bundle?

[stevendesu]

Nevermind

See "actual behavior" - I discovered the issue that was leading to such large builds in Brunch (or rather, such small builds in WebPack). Although the "additional rants" is still applicable, I plan on making separate issues for each of those.

Description

A relatively simple VueJS application built with Brunch is over twice the size of the same application built with WebPack

Expected behavior

All of the Brunch documentation, blog posts about Brunch, and Brunch tutorials suggest that Brunch produces smaller Bundles than WebPack. Even if larger, I wouldn't expect more than a 5-10% increase.

Actual behavior

The final size in WebPack was a 304k main.js file while Brunch provided me with a 660k vendor.js file and a 131k app.js file. That's a total of 791k -- 2.6x the size

I'm working on uploading these two repos to github. Will update the issue once I'm done.

Update: I was cleaning up the two github repos to ensure 100% feature parity between them and no extraneous code or unused NPM modules. It was during this cleanup that I noticed a minor difference in the .babelrc files. WebPack was passing modules: false to babel-preset-env. Removing this line increased the WebPack output from 304k to 788k. Still smaller than Brunch, but only 0.4% now instead of 160%

It looks like I never noticed this transform wasn't taking place because all testing was done in browsers that support ES6 modules: https://caniuse.com/#feat=es6-module

Environment

1. Brunch: 2.10.17
2. Node.js: v10.4.1
3. NPM: 6.3.0
4. Operating system: Ubuntu 18.04
5. Code editor: NVIM 0.3.0-dev

package.json contents

{
  "name": "template",
  "description": "Template",
  "private": true,
  "author": "Steven Barnett",
  "version": "1.0.0",
  "repository": "",
  "scripts": {
    "start": "rm -rf public/* && brunch watch --server",
    "build": "rm -rf public/* && brunch build --production"
  },
  "dependencies": {},
  "devDependencies": {
    "@fortawesome/fontawesome-svg-core": "^1",
    "@fortawesome/free-solid-svg-icons": "^5",
    "@fortawesome/vue-fontawesome": "^0",
    "babel-brunch": "^6",
    "babel-plugin-transform-runtime": "^6",
    "babel-preset-env": "^1",
    "babel-preset-stage-3": "^6",
    "bootstrap": "^4",
    "brunch": "^2",
    "clean-css-brunch": "^2",
    "node-sass": "^4",
    "uglify-js-brunch": "^2",
    "vue": "^2",
    "vue-brunch": "^2",
    "vue-router": "^3",
    "vuex": "^3"
  }
}

brunch config contents

module.exports = {
        files: {
                javascripts: {
                        joinTo: {
                                "vendor.js": /^(?!app)/,
                                "app.js": /^app/
                        }
                }
        },
        plugins: {
                vue: {
                        sass: {includePaths: ["node_modules"]}
                }
        },
        overrides: {
                production: {sourceMaps: true}
        },
        server: {run: true}
};

Other useful files, when present (log, bower.json etc.)

.babelrc

{
        "presets": [
                ["env", {"targets": ["last 2 versions"]}],
                ["stage-3"]
        ]
}

Additional Ranting (still valid)

I have a VueJS project that was originally being built by WebPack and I decided to give Brunch a try. In terms of getting up and running, it was fantastically superior. My old build config was 249 lines, and it didn't even work right (source maps were jacked up in production, static assets didn't always load in development, etc) - and that's after spending around 20 hours debugging the build scripts and eventually giving up. Meanwhile I installed Brunch, grabbed the proper plugins, and with very little effort I was able to get everything up and running.

Since then I've just been experimenting with various Brunch plugins, trying out different features, testing different ways to organize my code, and comparing the speed and final bundle size. This is when I started running into a hell of a lot of issues.

As I get time throughout the next couple of days I'll try to properly document and create issues in either Brunch or the appropriate plugins for all of the problems I've been having, but here's a short list of what kept me up late last night:

• Some combinations of plugins (notably appcache-brunch with any plugin that produces hashed filenames like digest-brunch or fingerprint-brunch) cause Brunch to return status code 1 (error) without dumping any errors to console and without giving any meaningful feedback. When this happens there's about a 50% chance that everything build perfectly and the error was superfluous, and a 50% chance that some files are missing
• Some plugin configuration didn't work as the docs suggested (notably extractCSS didn't seem to do anything when paired with vue-brunch, manifest didn't seem to do anything when paired with digest-brunch, and ignored didn't seem to do anything when paired with uglifyjs-brunch)
• The entryPoints config options is confusing and seems almost useless. I would expect providing an entryPoint to my app would save me the trouble of writing <script>require("index");</script> (since the entry point is known) and would lead to smaller bundles (thanks to not including every module and possibly thanks to tree-shaking, if that's a feature provided by Brunch). Instead the bundles ended up larger (789k vendor.js) and didn't even work (the contents of the vendor directory were not included in the global scope as expected, but instead only modules directly imported were seen)
• groundskeeper-brunch simply didn't work. It threw a meaningless error about needing to provide a version (which seems to be related to source maps?) and no output was produced
• vue-brunch forces hot module reloading (presumably because vueify forces it) which breaks source maps in development. This means when a bug is thrown I'm forced to guess-and-check debug it instead of looking at the actual line that failed
• NEW The paths.watched configuration option changes module names. I had a working application and I wanted to rename app to wwwsrc so it was more apparent that this was the source code for the front-end of my service, not the back-end. I added exports.paths.watched = ["wwwsrc"] to my brunch config and suddenly <script>require("index");</script> stopped working. Looking at the file produced, it looks like the new invocation is <script>require("wwwsrc/index");</script> -- why would this happen if there's only one index module and it resides in the only watched directory?

[paulmillr]

Thanks for writing the long post.

Some combinations of plugins (notably appcache-brunch with any plugin that produces hashed filenames like digest-brunch or fingerprint-brunch) cause Brunch to return status code 1

This needs to be fixed.

The entryPoints config options is confusing and seems almost useless

The only purpose is not needing to write <script>require('file')</script> — to combat content-security-policy, it's unallowed with it. We don't support tree shaking right now.

groundskeeper-brunch simply didn't work

Many of the plugins are community-made, the core team has no relations to 'em.

vue-brunch forces hot module reloading

I suggest you send a PR that makes that an option.

The paths.watched configuration option changes module names

Documentation should be updated, but this happens because we don't know all watched paths.

In the default config we assume user has his stuff in app so we strip app from the module names — see nameCleaner option. If a user has 5 watched directories, it makes sense to preserve parent app names to not put everything into one context.

[stevendesu]

@paulmillr

This needs to be fixed.

Glad I was able to find and document a real bug 😄

The only purpose is not needing to write <script>require('file')</script>

I'll do some more experimentation and see if a new issue should be created. When I used entryPoints I did not see any code running, then typing require("file"); into the developer console caused everything to run. Maybe I had some other issue that was preventing it from working auto-magically, or maybe I was mis-using the entryPoints option. I'll have to experiment and see. Similarly I'll try to understand why the vendor directory wasn't included and if this was something I did wrong or if it's a bug/feature of the entryPoints option

Many of the plugins are community-made, the core team has no relations to 'em.

I'll reach out to groundskeeper-brunch and vue-brunch (or vueify) about those specific comlpaints

Documentation should be updated, but this happens because we don't know all watched paths.

To clarify, does this mean that I can get the behavior I expect by making two changes to the config: one to set the paths.watched and another to change the nameCleaner function to remove the watched folder name?

Would it make sense as an improvement to automatically strip the path if there's only one folder in the watched path? In my case I changed paths.watched to ["wwwsrc"] -- so there was only one possible path for index.js: wwwsrc/index. If there were two watched paths then I could see the possibility for ambiguity, but with only one path it seems reasonable to assume.

Alternatively, instead of doing this with paths.watched (which also specifies test and vendor by default) maybe an extension should be made to the conventions option so that along with defining the assets and vendor key, you can define the app key (which will be stripped from module paths).

It just seems overly-complicated to do a simple task like "change the name of the folder". That feels like the kind of thing one should be able to accomplish with one line of config.