Closed KyleAMathews closed 9 years ago
I'd like to see an option like this as well. At least from my initial webpack experiments, it seems that being able to write the dev server output to disk would make working in parallel with another server much simpler. Right now I have a fairly complicated work-around of loading static assets from the dev server based on an environment variable, which works okay for a single bundle but breaks code-splitting.
The webpack-dev-server doesn't write files to disk. You can use webpack --watch
which writes files to disk. But why would you need to access the generated assets? This shouldn't be required.
When using with an existing server you should thread the webpack assets as blackbox that exists at a special URL.
Right, it makes a bit more sense now that I've worked with webpack a little more - it just necessitates my server having some notion of that blackbox in development, rather than always just serving assets from disk.
yesterday, a bad day, so I'll delete the things I wrote here. Webpack works with WebStorm very well.
You have to set in remote urls the mapping of your sources starting from "webpack:///."
PS: and it worked only for a minute. now, back to nothing
But why would you need to access the generated assets? This shouldn't be required.
While debugging the build process (webpack build configuration, webpack loaders configuration, project file structure), you could have to look into the generated files to understand what has gone wrong.
BTW, webpack-dev-server does not reload webpack config file when it changes either. So we have to restart the server. Luckily, the browser-side waits for it and catches up (thanks for that!).
+1
Writing to disk is not an option for the webpack-dev-server. Instead you can use webpack --watch
which does the same but writes files to disk + a static fileserver.
@sompylasar this is a very late reply, but you can examine the generated assets if you visit your dev server under the /webpack-dev-server path. I.e. if you're running it on 9000, http://localhost:9000/webpack-dev-server.
@diurnalist Sure, I know. This is how I do debugging in the browser. But I wanted to have the files in my text editor rather than in the browser's developer tools.
@sokra but that means you can't do hot-reloads...
@KyleAMathews how so? Nothing about hot reloads requires the assets be written to disk. I'm using it in a project right now without issue.
@diurnalist sorry wasn't clear — I want assets written to the disk. I was the one who originally created this issue ;-)
Right now I have to run both webpack-dev-server
and webpack -w
.
@KyleAMathews hmm, I'm still trying to understand why you need to run two webpack compilations. It seems irrelevant how the bundle is served. The only thing I can think is that somehow you need to do additional processing outside of webpack land on one of your output files? Feel free to send me an email (listed on my profile) - I've had to deal with a few weird things when integrating webpack into a big project, maybe my experience can be of use.
@KyleAMathews you can try setup git hook and run webpack on commit, pull etc.
@diurnalist I have two entry points, one of which I want served by webpack-dev-server for hot reloading (an admin page) and the other entry point I need compiled to disk so it can be loaded as part of a server generated React page.
@max-mykhailenko I need to see the results of my changes before committing ;-)
I have two entry points
You should have two configurations, because the target
option differs: web
and node
.
@sokra I was a bit unclear — the target for both entry points is the web — React is used to generate the initial html page that's sent but I still need the compiled js to animate the react app in the browser.
@KyleAMathews so, just to be clear (again, happy to discuss via email, these GH comment reply flows get a bit ridic after a certain point...) - does your generated HTML file need to include the script inlined? Or is it fine to include it as an external link? Obviously if the latter is true, you can simply link your script in:
<script src="http://localhost:9090/js/your-react-bundle.js"></script>
You'd just need to be able to change the host for when you deploy the app to a remote server, obviously.
If you need to actually inline your script... that's a different issue. But, I'd ask: why would you need to do that? For what it's worth, it's possible. I'm currently doing it to bootstrap some page-specific JSON into my app when it starts. The tricky part here is you need to understand what IDs webpack has assigned your modules. To do that, you need to parse the stats object webpack returns when a compilation completes. I have some code I could open-source that helps with this.
Basically, I have some script template that looks something like this:
webpackJsonp([], {
0: function (module, exports, require) {
var App = require(__APPLICATION_MODULE_ID__);
App.start(__BOOTSTRAP_DATA__);
}
});
And then when I'm generating my HTML page, I just read that template and replace the tokens with the webpack module id for the App module and the JSON string of bootstrap data. This works essentially by injecting a dummy webpack chunk on to the page that has no dependencies. You would need to ensure that you have loaded the main webpack library on the page before doing this, or else the webpackJsonp
function will not exist yet.
I basically want the server auto refreshing when I make changes in the code, similar to how the ember-cli works.
I've tried to follow allow this thread and the linked threads, but I'm still unsure of my current options.
It is possible to run Webpack Dev Server in "hot reload" mode (to support React Hot Loader, etc) while still writing the files to disk?
I'd like to add an argument for adding this option 😊. When using electron, in certain cases, you are only allowed to use files from a file:
path: https://github.com/atom/electron/blob/master/atom/renderer/lib/web-view/web-view-attributes.coffee#L201
@nickpresta As far as I know, not right now. You have to run a separate webpack -w
.
+1 for dev server writing to disk!
We also needed it for node's native modules (.node
). They can't be loaded from web server.
+1 for writing to disk. Just adds confusion when starting out.
+1 for not only serving the compiled files, but also writing the compiled files to disk.
This would be useful when using webpack + BrowserSync to refresh when static assets (ie., CSS) change.
I have released a plugin that forces webpack-dev-server to write to the file system.
@gajus Thank you for that!
@gajus thank you.
+1 Still hoping for an official resolution to be provided
+1
+1 Make it optional at least, please
A good solution is to just use Webpack, which actually writes to the disk, which you can pair with something like BrowserSync. It seems like WebpackDevServer is meant only for non-writing-to-disc development. :]
var webpack = require("webpack")
var browersync = require("browser-sync")
webpack({
watch: true,
//put your config here
}, function(error, stats) {
if(!!server && !!server.active) {
server.reload()
}
})
server = browersync({
server: "./build",
port: 8080
})
There is a plugin for this. Whats everyone upset about? Just use it.
On Dec 9, 2015, at 21:59, Andrew McPherson notifications@github.com wrote:
A good solution is to just use Webpack, which actually writes to the disk, which you can pair with something like BrowserSync. It seems like WebpackDevServer is meant only for non-writing-to-disc development. :]
— Reply to this email directly or view it on GitHub.
@gajus Drop a link, bro! :]
@gajus Unfortunately, your plugin writes only bundle.js and skips other files (e.g. images, fonts). Although its not crucial. Using data-urls for this stuff will solve problem.
I was having a lot of problems with launching web-dev-server via gulp and writing right config for it. So, I've started using webpack-dev-server --content-base dist/
and all problems went out! Highly recommend to use this way. I don't need to write bundle to disk any more
+1 for a flag that permits writing contents out to disk.
Unfortunately, your plugin writes only bundle.js and skips other files (e.g. images, fonts). Although its not crucial. Using data-urls for this stuff will solve problem.
It writes the same what webpack
program would. If you have not configured webpack program to write whatever additional resources, it will not write them.
Unfortunately, your plugin writes only bundle.js and skips other files (e.g. images, fonts). Although its not crucial. Using data-urls for this stuff will solve problem.
@wailorman This has been fixed in the latest release. https://github.com/gajus/write-file-webpack-plugin/issues/14
@gajus Thank you very much! Your plugin is really awesome
@sokra
But why would you need to access the generated assets?
Suppose you're writing a Chrome Extension. These aren't loaded from a server. The bundle file is needed to be loaded from disk. Not adding this option requires setting up a separate Grunt watch task just to call webpack. That's messy since for other bundles I do want to load from the "dev server".
@gajus perfect! exactly what I needed. Thx!
I'll add my super random need for this as a +1.
I am working on a proof of concept for a product that has an HTML5 UI on an embedded (vehicle) OS. The HTML talks to the embedded component over WebSocket and does not have any sort of internet access. There are points in the communication which the embedded component passes a path to the HTML5 app containing assets such as images for display. I am currently creating a tunnel so the app can grab the static files via ip + file path and running nginx on the embedded component to serve the static files (hack) while I run the web app from my mac on the same network. It would be ideal if I could run these on the same OS and launch the index.html file (referencing the compiled index.js file) into the web view so that its url is file:// instead of http:// so that it has access to the file system. To do this I need the compiled index.js (I think)
@justinjdickow I'll add my super random need for this as a +1.
@gajus I did end up finding that and it worked perfectly for my needs. Thank you!
@diurnalist ,@KyleAMathews can i have any single command which will able to create my bundle.js file in my app not with --watch and that should able to run webpack-dev-server also ?
combination of webpack --watch & webpack-dev-server --content-base build/
Another usecase:
Currently, whenever I'm working on the mobile app, I have to fallback to webpack --watch
, and doing so means I don't have anymore hot reloading when "previewing" my devs in the browser. I need both hot reloading + writing to disk
Will try plugin of @gajus thanks
@gajus excelent plugin, thanks!
Thank you for the plugin @gajus! For the record, my use case is I'm running selenium tests which expect a bundle to be there on the file system. Currently we're all running webpack dev server, but whenever someone wants to run a selenium test they need to remember to kill the dev server and run webpack --watch
instead.
My solution is putting "emit" hook into the build process.
const compiler = webpack(config)
compiler.plugin('emit', (compilation, callback) => {
const assets = compilation.assets
let file, data
Object.keys(assets).forEach(key => {
// if (key.match(/\.html$/)) {
file = path.resolve(__dirname, key)
data = assets[key].source()
fs.writeFileSync(file, data)
// }
})
callback()
})
app.use(devMiddleware(compiler, {
noInfo: true,
publicPath: config.output.publicPath
}))
app.use(hotMiddleware(compiler))
I'm developing an app that has several entry points — one of which needs a custom html file that I'm generating using a View in my hapi.js server.
Is there a way I can configure the dev-server to write the generated js files to disk? Right now I either have to have another webpack watcher to compile files or stop and manually compile the files when I make a change to that particular part of the code.