Webpacker: Why is the manifest.json generated on the disk when the dev server is running?

Created on 2 Jan 2020 · 1Comment · Source: rails/webpacker

@gauravtiwari Why is the manifest created to the disk files rather from the dev server?

I'm trying to get the webpack-dev-server to work with React on Rails and I noticed that the webpacker code always looks for the manifest on the disk, rather than from the dev server URL (
http://localhost:3035/webpack/development/manifest.json)

Is there an advantage to doing this?

https://github.com/rails/webpacker/blob/master/package/environments/base.js#L43-L50

  result.append(
    'Manifest',
    new WebpackAssetsManifest({
      integrity: false,
      entrypoints: true,
      writeToDisk: true,
      publicPath: config.publicPathWithoutCDN
    })
  )

Source

justin808

👍1

Most helpful comment

A couple advantages I can think of:

Reading from disk is faster. On my machine (MacBook Pro, 15", mid 2014, 2.8 GHz Quad-Core Intel Core i7), Pathname#read several orders of magnitude faster than Kernel#open provided by 'open-uri'. See benchmark code here — this measures from the perspective of the Rails server and doesn't take into account differences in the webpack dev server writing to disk and/or reading from memory.
```
   user     system      total        real
open(url).read  0.497777   0.269930   0.767707 (  6.950559)
Pathname.new(path).read  0.009915   0.020251   0.030166 (  0.031719)
```
Reduced complexity. I'm unsure of the use case for React on Rails, but I assume reading from URL is necessary only for the local environment. Since most deployed apps typically apply aggressive caching to static files served over HTTP/S from the public directory, reading from disk makes sense in remote enviroments. The onus would be either on the Webpacker project to maintain logic for separate Webpack options in development and production, i.e, writeToDisk: isProd, or on the developer to configure their production web server or CDN to avoid improperly caching manifest.json.

rossta on 2 Jan 2020

👍3

>All comments

A couple advantages I can think of:

Reading from disk is faster. On my machine (MacBook Pro, 15", mid 2014, 2.8 GHz Quad-Core Intel Core i7), Pathname#read several orders of magnitude faster than Kernel#open provided by 'open-uri'. See benchmark code here — this measures from the perspective of the Rails server and doesn't take into account differences in the webpack dev server writing to disk and/or reading from memory.
```
   user     system      total        real
open(url).read  0.497777   0.269930   0.767707 (  6.950559)
Pathname.new(path).read  0.009915   0.020251   0.030166 (  0.031719)
```
Reduced complexity. I'm unsure of the use case for React on Rails, but I assume reading from URL is necessary only for the local environment. Since most deployed apps typically apply aggressive caching to static files served over HTTP/S from the public directory, reading from disk makes sense in remote enviroments. The onus would be either on the Webpacker project to maintain logic for separate Webpack options in development and production, i.e, writeToDisk: isProd, or on the developer to configure their production web server or CDN to avoid improperly caching manifest.json.