Closed dbalatero closed 4 years ago
Hi @dbalatero, thank you for the feedback!
Extracting a config from Webpacker: The gem does not have such function. It would better for Webpacker to have it. FYI someone tried eject
function https://github.com/rails/webpacker/pull/1916. This pr may help you.
The next, about Hot Module Replacement: I proposed in my blog post using rack-proxy to enable HMR. I think that installing such rack middleware can be supported in my gem. So, how about starting/stopping webpack-dev-server along with rails? My thought is that webpack-dev-server should start manually separated from rails s. Foreman
may be a choice If you want to start both together.
The last is about the test mode. I run npm run build
sometimes manually in my project, when it is needed before testing request specs, though that takes labor. CI is the same. This workflow can be improved, but no ideas.
I am going to think about hot reload in development mode and pre-compile in test mode.
FYI: I'm trying pre-compile in test by using rspec's before :suite
hook at #11.
@nikushi cool! I'd be down to work on a PR to add rack-proxy to enable webpack-dev-server/HMR passthrough. I agree that webpack-dev-server should be started alongside Rails manually.
The webpack plugin for browsersync is pretty handy in this regard. You get a reload whenever a js, rb or erb file is changed. Not for everyone, but this flow is nice to work with once you have it set up.
Basicly, webpack-dev-server is proxys requests based on url. Requests to /javascripts/webpack/
(my output folder) get proxyed to https://localhost:8081/*
(live wpd server output). All other rails requests get dutifully passed to the 3000 port like normal.
const jsonPlaceholderProxy = proxy('/javascripts/webpack/', { //change to match your output folder
target: 'https://localhost:8081',
changeOrigin: true, // for vhosted sites, changes host header to match to target's host
logLevel: 'debug',
secure: false,
ssl: {
key: fs.readFileSync('./ssllocal/server.key', 'utf8'),
cert: fs.readFileSync('./ssllocal/server.crt', 'utf8')
},
pathRewrite: {
'^/javascripts/webpack/(.*)': '/$1' // rewrite path
}
});
}
// later in plugins (there are better ways to detect WDS, but we just set explicit flags)
process.env.WPD_HMR !== 'false' ? new BrowserSyncPlugin(
// BrowserSync options
{
host: `${subdomain}.domain.me`, // or localhost
port: 3002,
watchOptions: {
ignoreInitial: true,
ignored: '*.txt'
},
files: ['./app/**/{*.erb,*.rb}'],
open: false,
proxy: {
target: `https://${subdomain}.domain.me:3000/`, // or localhost
middleware: [jsonPlaceholderProxy]
},
https: { key: './ssllocal/server.key', cert: './ssllocal/server.crt' }
},
{ reload: false } // prevent BrowserSync from reloading the page and let Webpack Dev Server take care of this
) : noop()
This is a departure from other solutions, but at least it works with HMR and style injection. Plus its nice to have erb files reload the browser when saved. Hope this is useful.
pre-compile in test mode.
Now you are able to use this function with v0.3.0 🚀.
Hi @nikushi! Funnily enough I started on a gem just like yours at https://github.com/dbalatero/webpack-lite a while back. I saw your article https://medium.com/@nikushi/replacing-rails-webpacker-with-vanilla-webpack-54b7ea90d913 and got curious about your project. I like where it's at so far!
I'm curious about a few things before diving into trying this gem:
How do you propose porting a Webpacker config from a production app to plain Webpack? My thought was to actually dump out the final Webpacker config to a file and then make surgical edits to it to bring it back to parity with what Webpacker provides behind the scenes.
Is there any interest in replicating the compile-on-first-request functionality that Webpacker has? Or does that become irrelevant as long as you:
webpack-dev-server
in development modewebpack-dev-server
in test mode