Should I move from brunch to webpack?

Phoenix Forum Questions / Help
1

Configure webpack looks harder than brunch. I followed some tutorials and i understand webpack configs. I just want to use for js, and css files. My concern is deploy. While Deploying with webpack
will i need alot new configures than development configs?

2

The only difference between dev and prod with webpack is the way You start the script…

In my case, it’s just like this (in the scripts section of my package.json).

    "watch": "webpack --watch --color",
    "build:dev": "webpack --progress --colors --watch",
    "build:prod": "NODE_ENV=production webpack --progress --colors -p",

More or less… You pass -p for production.

Then in webpack.config.js I can select which plugin to add depending on NODE_ENV.

2 Likes
3

Thanks then i will move to webpack

4

Do not forget to update config/dev.exs from the web part if You want to fully use webpack.

watchers: [yarn: ["run", "watch", cd: Path.expand("../../../assets", __DIR__)]]

The path I am using correspond to an umbrella application, with an assets path at the root of the project. Please adapt for your configuration.

This activate watcher mode in development, and allow automatic reload when updating js files. It uses the watch script, with yarn, as defined above in my last post.

1 Like
5

If the project is big enough, I’d recommend going modular with files for development and production (e.g. https://github.com/vuejs-templates/webpack/tree/develop/template/build). Once you get the basic workflow, is always the same; adding plugins, configuring loaders and you’re done.

I never liked Brunch, it offers less flexibility than Webpack IMO. Also with Webpack 4, the configuration is easier than before.

1 Like
6

Project is big but only for me :smile:
I have been learning web programing since 10 mounth. I feel like everything in web development unstable. Too many new things happening while i have been learning. Really hard to adopt. Just yesterday webpack4 final released. Now i need to adopt new webpack4 configs.

1 Like
7

@kokolegorille If -p enabled production, than what is the point of :

1 Like
8

It should be redundant as -p is a shortcut for:

--optimize-minimize --define process.env.NODE_ENV="production"

2 Likes
9

oh, that is not necessary…

-p should be enough :slight_smile:

1 Like
10

Thanks @kokolegorille and @peerreynders, didn’t know if I was missing something in the webpack ecosystem as I’ve not actually delved too far in to it yet. ^.^;

11

Now that webpack 4 is out, it’s not -p anymore, it’s

--mode development
# or
--mode production

I tried on one of my config… after adapting to new syntax, the bundle is 10x bigger than the older one!

It may be fast, but config needs full rewrite.

As long as I cannot reduce the bundle size, I will stay to v3.

3 Likes
12

In the changelog of webpack 4 I could read the following big change…

process.env.NODE_ENV are set to production or development (only in built code, not in config)

How ironic, but now I really need both :slight_smile:

“build:prod”: “NODE_ENV=production webpack --mode production”,

Now it’s fast and the bundle is way lighter.

2 Likes
13

Lol, how duplicative… ^.^;

14

Actually, you have been right all along - i.e. you needed

  • NODE_ENV=production because your configuration files depend on that environment variable to select your production configuration.
  • --define process.env.NODE_ENV='production' “defines a free variable”

WTH???

Lets say you have this in your front end code:

if(process.env.NODE_ENV !== 'production') {
  console.log('Not Production');
}

and in your package.json scripts:

"build": "webpack --define process.env.NODE_ENV=\"'production'\"",

the define causes webpack to replace process.env.NODE_ENV with 'production', i.e.

if('production' !== 'production') {
  console.log('Not Production');
}

which webpack promptly rewrites as

if(false) {
  console.log('Not Production');
}

which uglify will promptly strip out on the minimization pass.

This setting has caused no end of confusion since webpack 2.

2 Likes
15

Now I understand why I hate JS so much. It’s confusing keeping up with changes…

Last post now mention…

This is now fixed in webpack 4. Setting mode: production or development also sets the proper NODE_ENV

3 Likes
16

FYI: It seems that the recommendation is to use the env option rather than environment variables to drive the configuration i.e.:

"build": "webpack --env.target production",

and then in the webpack.config.js:

module.exports = (env) => {
  return env.target === 'production' ?
    productionConfig() :
    developmentConfig();
};

In 4 you can hijack the --mode setting:

module.exports = () => {
  const args = process.argv;
  const modeIndex = args.findIndex(v => v === '--mode') + 1;
  const mode = 0 < modeIndex && modeIndex < args.length ?
    (args[modeIndex]).toLowerCase() : 'development';

  return mode === 'production' ?
    productionConfig() :
    developmentConfig();
};
4 Likes
17

I added some thoughts about migrating to Webpack 4 on my demo app.

Which is also available as github pages

For those who wants to try Webpack 4 w/ Phoenix.

@peerreynders Thanks for sample config. I will try to integrate to my setup.

7 Likes
18

Seems like webpack 4 will be the default:

8 Likes
19

phoenix 1.3.1 includes webpack4 ?

Edit: answer is no

20

Awesome work. Got webpack working, although still experiencing some quirks. Inside of the src/ folder I’d like to still have a css and a js folder, but things don’t seem to pick up from it. any ideas?