Live data from Hacker News

Browserify vs. Webpack – Configuration isn't evil

medium.com

31–32 of 32 posts

Re: Browserify vs. Webpack – Configuration isn't evil

#31

All this time I've just been using a boring old shell script that runs browserify with the Babel plugin, and then uglify. Hook it up to npm scripts and I've got all I need, in about half a dozen lines spread across two files. Browserify is useful because concatenating a bunch of JavaScript files is hardly the right way to be doing things. Babel I have to use because all browsers struggle with ES2015 to an extent. Ugl…

I too am leaning towards converting our ugly gulp directory into npm scripts. I'm though less sure about how to handle replacing relative image paths in CSS & JS with ones on cloudfront. Have you dealt with things like these? Would love to see how!

I haven't deal with things like that - though it must be a common problem so I'd assume there's a tool somewhere to do it.

Re: Browserify vs. Webpack – Configuration isn't evil

#32
post #10
post #9

A bit off topic: any advice about integrating Webpack with Rails? Looks like the most popular gem to do that has only 19 stars on github... https://github.com/danott/webpack_rails

Your best bet is no integration at all. Just set up webpack to read from ./app/assets and output to ./public. Run it separately, preferable with a foreman Procfile for development (I've used Procfile.dev before).

And what will the output to ./public be like? If webpack is using it's own cache busting asset links, how do we use that against sprockets? I think I'll just still stick to Grunt/Browserify
Post reply on HN