Vendor chunkhash changes when app code changes

I'm trying to split my vendor code from my app code and got it all working. However, every time I change some code in my app and create a new build, the vendor file gets a new chunkhash and thus is downloaded by the clients again. The contents are exactly the same though.
Here is a fully working small example showing the problem: https://github.com/kevinrenskers/chunkhash-problem
And as you can see, the contents of these files are 100% identical even though the chunkhash keeps changing:

I am also experiencing this issue

Looks like a conflict between the plugin and the lastest changes. You could try a previous webpack version (thay had a bug that [chunkhash] didn't change when the content change).

Any idea which webpack version I should try?

Seems that going back to 1.10.1 works. 1.10.2 and up break the chunkhash as described above.

It doesn't "break" it, it fixes it. The chunk hash should change when the hash of the chunks change... ;)

But if the contents of the vendor file don't change then its hash shouldn't change right? How else are we supposed to have long term caching if the filename changes every time I make a change in my app code?

That's caused by the chunk-manifest-webpack-plugin. It move the hashes of the child chunks out of the entry chunk. I propably need to rewrite it...

I don't really understand. Isn't the whole point of chunk-manifest-webpack-plugin to remove the child chunk hashes exactly so that the contents of the entry chunk don't change and thus its hash should stay identical? It does work like that with 1.10.1.
Yet, you're saying that 1.10.2 have actually fixed this rather then breaking it. So, is the chunk-manifest-webpack-plugin doing something wrong? Or webpack? Or in other words, how am I supposed to have a working setup where changing the app code does not change the vendor's file name? :) Like I said it seems to work with 1.10.1 but your comments confuse me..
Are you able to get such a setup working with the latest webpack, as I've tried in the example project (linked above)?

I'm attempting the same setup as @kevinrenskers and naturally have run into the same issue. If we possibly can come up with a workaround I'd appreciate it :thumbsup:

Even going back to 1.10.1 only fixes the problem some of the time. Other times I create a build, the vendor file still gets a new file name. A fix would be extremely welcome.

We're seeing this issue as well, any consistent fix would be great.

same problem. I remove the chunkHash and use my own hash now :(.

If you're willing to share, what method are you using to produce a hash?

@lsanwick I just add my release date after the script path in the html file (eg: lib.js?v=20150818).  :(

Makes sense, @bebraw and I started to investigate different solutions for this and it is just a bug. We hope this can be fixed :)

+1 for this issue !

:+1: for this issue as well

Adding the webpack-md5-hash plugin in addition to the chunk-manifest plugin allowed me to work around this bug and get my non-changing vendor bundle to stay the same.

Great solution! Works like a charm.

This all seems a little broken to me. Shouldn't the hash be applied at the file level instead of the chunk level? If a chunk produces an app.js and a vendor.js, I don't care if the chunk changed. I care if app.js and/or vendor.js files changed, because this ultimately determines if the client needs a new copy.

Sadly adding webpack-md5-hash doesn't work either, because in the vendor files some references to modules in the main file change yet the hash stays the same. This completely breaks the entire app.

Hmm, not seeing this behavior in  my toy example.  are you using OccurenceOrderPlugin ?
My plugin list:
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
minChunks: Infinity
}),
new webpack.optimize.DedupePlugin(),
new ManifestPlugin(),
new ChunkManifestPlugin({
filename: 'chunk-manifest.json',
manifestVariable: 'webpackManifest'
}),
new ChunkManifestPluginWriter(),
new WebpackMd5Hash(),
new ManifestPlugin(),
new webpack.optimize.OccurenceOrderPlugin(),
new webpack.optimize.UglifyJsPlugin({
compress: {
warnings: false
}})
Hack to get around watch not triggering :
// Force output chunk-manifest after each build.
// TODO: figure out bug chunk-manifest-webpack-plugin that makes it miss
// webpack watches
class ChunkManifestPluginWriter {
apply(compiler) {
compiler.plugin('emit', (compilation, compileCallback) => {
const stats = compilation.getStats().toJson();
const result = {};
stats.assets.filter((asset) => {
return asset.name.endsWith('.js') & (asset.chunks[0] > 0);
}).forEach((asset) => {
result[String(asset.chunks[0])] = asset.name;
});
compilation.assets['chunk-manifest.json'] = new RawSource(JSON.stringify(result));
compilation.mainTemplate.plugin('require', (_, chunk, hash, chunkIdVar) => {
return _.replace('"CHUNK_MANIFEST"',
'window["webpackManifest"][' + chunkIdVar + ']');
});
compileCallback();
});
}
}

I'm using webpack.optimize.CommonsChunkPlugin, chunk-manifest-webpack-plugin, webpack.optimize.DedupePlugin, webpack.optimize.OccurenceOrderPlugin and webpack.optimize.UglifyJsPlugin.
However, I am calling OccurenceOrderPlugin with a boolean true (webpack.optimize.OccurenceOrderPlugin(true)), would that matter?
Not sure what your ChunkManifestPluginWriter and ManifestPlugin plugins are?

Looks like related issue: https://github.com/webpack/webpack/issues/1479

:+1: for webpack-md5-hash + '[chunkhash]'

What about [hash], is it stays the same with webpack-md5-hash?

I keep having this problem where in my vendor file a number like this changes (notice the highlighted 360, this used to be 359 in the build before this) yet the hash stays the same. No idea why that number changes in the first place.

I think it's every time a new module is created and imported to my app. This then messes with the module numbers in vendor.js as well.

I love webpack but it looks the hash story is completely broken (see the open issues below), making it impossible to implement long term caching.

Vendor chunkhash changes when app code changes #1315
Document what changes a hash/chunkhash #1486
Different hash on different computers #1479

This particular issue has been open for a couple of months now.
Is anyone actively looking into this issue?

I'll look into this after returning from vacation...

:+1: for webpack-md5-hash + '[chunkhash]'. It's really helpful.

It seems like this is partly an issue of using integer module IDs. If there were a way to only refer to modules via string IDs like suggested in https://github.com/webpack/webpack/issues/579 , that could be a good way around this?

+1 also ran into this problem today. It's weired, I am having 3 chunks:

app.bundle.js (chunkhash changes when app.bundle.js changes)  <-ok
vendor1.bundle.js (chunkhash changes when app.bundle.js changes) <-problem
vendor2.bundle.js (chunkhash stays the same when app.bundle.js changes) <-ok

Would be great if we could use the same filename interpolation options (like <hashType>, <digestType>, <length>) that loader-utils makes available to file-loader.

Apparently, chunk-manifest-plugin does extract the manifest, but the chunkhash is calculated prior to that.

mark, i had the same issue,  hope webpack coule fix it.

You can solve it by creating separate 'entry chunk':
plugins: [
        new webpack.optimize.CommonsChunkPlugin({name: 'vendor'}),
        new webpack.optimize.CommonsChunkPlugin({name: 'meta', chunks: ['vendor']})
]

It marks meta.js as entry chunk instead vendors.js.
As result you'll get three files:

main.[hash from app content].js
vendor.[hash from vendors content].js
meta.[hash].js – webpack runtime, which hash depends on app and vendors file names

@vlkosinov separating the Webpack runtime solves one issue (any addition/removal of modules forcing an update of the contents of the file that includes the Webpack runtime), but does not seem to solve the underlying issue described here, which is that any time a module ID gets changed, every file that references that module gets updated, so in the scenario of:

main
vendor
meta

It is still possible for a change to contents of "vendor" to have a ripple effect of changing a module reference in "main".

Yep if I add a new module to my app source, then my vendor hash still changes even though that file was not changed at all.

@bregenspan @kevinrenskers yes, you are right

@bregenspan @kevinrenskers try to disable OccurenceOrderPlugin and this workaround should work

Removing OccurenceOrderPlugin doesn't make any difference to me. If I add another module to my source and import it in my main entry point, the vendor's file hash still changes.

Can you provide example with meta.js chunk and without CommonsChunkPlugin, when it problem reproduced? I can't repeat it with your example: https://github.com/kevinrenskers/chunkhash-problem

Okay I updated my example to be more real-world like, where I have a vendor.js file listing my vendor dependancies instead of listing them individually in the webpack config. You can edit entry.js, enable the import of test.js and re-run the build. The vendors file in the build will then get a new hash, without without OccurenceOrderPlugin.

I'm seeing this issue on 2.0.0-beta as well.  Adding a new module changes module IDs throughout many chunks.
Is a fix even on the horizon?

Any news? Using webpack 1.12.4 and there is an issue. I checked multiple times with multiple configurations: [chunkhash] of 'vendor' is changing after any change in entry.js or any module.js.
However, content of vendor.js is not changing. It's only [chunkhash].
And, if it matters, I'm using webpack like this: "npm run deploy", where "deploy" equals to "env NODE_ENV=production webpack -p".

@sokra Are you back from vacation? :) It would be great to have anyone look into this, get an idea of when / how this can be fixed, etc.

https://github.com/webpack/webpack/tree/master/examples/chunkhash

@sokra thanks!  This example with the latest Webpack does indeed resolve one of the issues (and with many fewer plugins required): changes to an 'app' chunk no longer invalidate a 'vendor' chunk (or a require.ensure code-split chunk).
However, another problem remains: adding or removing a module to/from an 'app' chunk introduces changes into all chunks -- including vendor and code-split, even though they do not import that module or any that depend on it.

However, another problem remains: adding/removing a module to/from an 'app' chunk introduces changes into all chunks -- including vendor and code-split, even though they do not import added/removed module or any that depend on it.

Yes, because there is no "state" between compilations. You need to store the used module and chunk ids to a records json file to keep them between compiler invocations. Use the recordsPath option.

The fact that we need "state" between compilations seems like a big red flag to me. If I compile the same code, I should get the same hash. Why do we need to know what happened in the past to do that? If we didn't change any of the code going in to the vendor chunk, there is no way its hash should change.

That's an unfortunate workaround; it complicates deploys. It appears that only thing changing in the files that shouldn't is module IDs (this is with the OccurrenceOrder plugin).

If I compile the same code, I should get the same hash.

Yes, that's true.
But if you don't compile the same code this may affects the whole compilation. Each module gets a unique id. By default this id is the index of the module in the modules array. The OccurenceOrderPlugin orders the modules in a way that most referenced modules come first and the order is the same for each compilation. This way the bundle size is as small as possible. If you change your code in a way that adds or removes modules it will affect all module ids.
As this is bad for long term caching the records allows storing and restoring the module ids to keep them between builds. This is the most size efficient solution.
Another solution (not implemented yet) would be to use other module ids. I. e. filename hash instead of numbers. This would affect the bundle size in a negative way but you don't need state between compilations. (Hint: here is a plugin that changes the module id format: https://github.com/webpack/webpack/blob/master/lib/NamedModulesPlugin.js)
Yet another solution would be to compile the vendor chunk separate from the main chunk. This way each one have it own module id numbering and only the vendor chunk affects the main chunk but not the other way. You can to use the DllPlugin to do this.
Summary:

state between compilation
vendor change affects main
main change affects vendor
small bundles
tool

no
yes
yes
yes
nothing

yes
no
no
yes
records

no
no
no
no
hash module ids

no
yes
no
yes
dll

Using a hash for the modules id seems like the only way to really fix this. How much bigger are we talking about if we use hashes instead of indexes?
Maybe we could use the first X number of characters from a base64 encoded hash. If there are conflicts, increment X until there are none. This isn't as good as using the full hash, but it would be better than using an index.

@sokra thanks for the info on NamedModulesPlugin, didn't know about it (and hope you had a good vacation)!
Testing it out on a very large real-world example entry chunk, I'm getting pretty unexpected results that suggest that gzip can more than mitigate the size increase from using named modules:

numeric module IDs
named module IDs

raw
1,070,284B
1,128,741

gzip
238,046B
229,442B

It isn't surprising that gzip helps a lot, by replacing each module ID string with a pointer (most of the added weight from using named module IDs is due to repetition). But that named module IDs + gzip would work better than the integer IDs + gzip seems pretty strange. Will check if this pattern holds with a more minimal example that I can share in a repo.

I can also vet named using named module id does not incur that heavy penalty as feared. On 560 modules code, I tested 6 combinations both for vendor and app module:

hashed module id
named module id
md5 of named module id
gzip + hashed module id
gzip + named module id
gzip + md5 module id.

I tested this for both non-uglified and uglified code.
Named module id is the best choice to go for its added benefits - (a) consistent hash of JS files (b) easily know which modules are going in the code (specially on uglified code)
non uglified
non gzipped
| normal | named chunk | gain (bytes) | md5 named chunk | gain (bytes)

------| ----- | ----- | ----- | ----- | -----
vendor | 2225656 | 2298001 | 72345 | 2280449 | 54793
app | 982102 | 1001823 | 19721 | 996401 | 14299
gzipped
| normal | named chunk | gain (bytes) | md5 named chunk | gain (bytes)
------| ----- | ----- | ----- | ----- | -----
vendor | 487061 | 482705 | -4356 | 502583 | 15522
app | 182898 | 180409 | -2489 | 186553 | 3655
uglified
non gzipped
| normal | named chunk | gain (bytes) | md5 named chunk | gain (bytes)
------| ----- | ----- | ----- | ----- | -----
vendor | 693695 | 767928 | 74233 | 750095 | 56400
app | 366639 | 390586 | 23947 | 385093 | 18454
gzipped
| normal | named chunk | gain (bytes) | md5 named chunk | gain (bytes)
------| ----- | ----- | ----- | ----- | -----
vendor | 218229 | 219029 | 800 | 232357 | 14128
app | 93512 | 94546 | 1034 | 98772 | 5260
I would suggest let's change the default behaviour of webapck to named modules id.

Did anyone who tested out the NamedChunkPlugin use expose-loader?  Enabling the plugin breaks the loader for me.

I'm trying to use the NamedModulesPlugin in my application but I'm getting an exception thrown by keys.js from the core-js module
This is keys.js:
require('../../modules/es6.object.keys');
module.exports = require('../../modules/$.core').Object.keys;

/*****************
 ** WEBPACK FOOTER
 ** ./~/core-js/library/fn/object/keys.js
 ** module id = ./node_modules/core-js/library/fn/object/keys.js
 ** module chunks = 3
 **/

And this is the exception I'm getting:
Uncaught TypeError: Cannot read property 'keys' of undefined

Seems like the require statement for $.core doesn't resolve correctly.

@sokra Have we solve this issue? It lasts a long time! Nearly five months.

@BorelTung FYI
https://github.com/kevinrenskers/chunkhash-problem/commit/3969b5ac2233a933fe35b1338106cc13fd7caddb
<EMAIL_ADDRESS>

There is a lot of discussion on this issue so apologies if this is no longer relevant.
I have an update regarding diurnalist/chunk-manifest-webpack-plugin#7 as referenced in the original issue.
Refer to this analysis and the proposed solution (diurnalist/chunk-manifest-webpack-plugin#9) which doesn't require changes to Webpack itself.
I haven't had any response from @diurnalist this month but I am presuming the holiday period is at play.
While we are waiting perhaps others can install from bholloway/chunk-manifest-webpack-plugin (the source of the pull-request) and check whether this fixes their own use case.

diurnalist/chunk-manifest-webpack-plugin#9
NamedModulesPlugin
none works
new webpack.optimize.CommonsChunkPlugin({names: ["vendor", manifest]}), with manifest extract out
webpack md5 hash

None works

@bhamodi sorry , I make a mistake
@kevinrenskers , I try your solutions , it works if chunk nums doesn't change.
npm install we-pepper -g;
pepper init demo;
cd demo;
pepper pre;
# edit src/pages/index.jsx, remove about page entry, both the import and route config
pepper pre;

then get following output. vendor hash has not change.
➜  demo  pepper pre
Hash: bfbf7a48f33bf6a9e709
Version: webpack 1.12.11
Time: 9253ms
                 Asset       Size  Chunks             Chunk Names
js/commons-e9219f0d.js      35 kB    0, 3  [emitted]  shared
   js/home-646aa985.js    9.05 kB    1, 3  [emitted]  home
 js/vendor-5a9e0e26.js     131 kB    2, 3  [emitted]  vendor
            index.html  648 bytes          [emitted]
   [0] multi vendor 40 bytes {2} [built]
    + 199 hidden modules
➜  demo  vim src/pages/index.jsx
➜  demo  pepper pre
Hash: d72ff25390f520660578
Version: webpack 1.12.11
Time: 8205ms
                Asset       Size  Chunks             Chunk Names
js/shared-9f5500d8.js    34.7 kB    0, 3  [emitted]  shared
  js/home-1fb4ec5e.js    6.85 kB    1, 3  [emitted]  home
js/vendor-5a9e0e26.js     131 kB    2, 3  [emitted]  vendor
           index.html  647 bytes          [emitted]
   [0] multi vendor 40 bytes {2} [built]
    + 194 hidden modules
➜  demo

I use @kevinrenskers 's solution to extract manifest out, and inline into html script tag(view dist/index.html after pepper pre)
chunk num and order effect the manifest, and also vendorhash reference.
I use AggressiveMergingPlugin & MinChunkSizePlugin to merge small chunks, so subtle code change will not effect chunk num.
Note: I create pepper to extract out webpack config and dev dependencies out our projects, guys should have a try

After I changed my example project to use the new solution with named hashes and extracting the manifest chunk I've not had any problems anymore.

@kevinrenskers :+1: :smile:

After I changed my example project to use the new solution with named hashes and extracting the manifest chunk I've not had any problems anymore.

Looks great. You could ask the html-webpack-plugin if they support inlining of js assets on there API.
I also added https://github.com/webpack/webpack/blob/master/lib/HashedModuleIdsPlugin.js if you are scared about exposing path info... (it's only in the 2.0.2 version)

For me it was expedient to implement the .json inlining with something I knew, which was Gulp Inject.
To that end I have gulp-inject-webpack-plugin post-process an index.html as extracted by indexhtml-webpack-plugin. I have a detailed readme specifically geared to long term caching.
Just to be clear there is no dependency on Gulp.
Gulp Inject has some really good features and I'm sort of locked into their injection comments in a lot of my legacy projects. So even though this plugin is a bit of a frankenstein it is a good solution, at least for me.

@kevinrenskers I also had trouble until I discovered options.output.chunkFilename.
It seems you have dropped the chunk-manifest-webpack-plugin. Does this give the correct result?

Yep

Ok @kevinrenskers I think I see what it is doing. Nice work.
Would you say that chunk-manifest-webpack-plugin is subject to the hash change problem whereas your solution is not.
And therefore there is no bug to solve in this issue, as such. It is just that chunk-manifest-webpack-plugin was always an incomplete solution given the Webpack architecture.

@bholloway I don't feel that chunk-manifest-webpack-plugin is an incomplete solution. @kevinrenskers solution is very html-webpack-plugin focused, whereas I find chunk-manifest-webpack-plugin to be quite useful on it's own since I don't need html-webpack-plugin. The key really is the need for NamedModulesPlugin as well as WebpackMd5Hash with a proper use of chunkFilename.

Yeah chunk-manifest-webpack-plugin can be used just fine, I just didn't use it because I am using html-webpack-plugin and dropping the manifest chunk in there, then inlining it.
WebpackMd5Hash is not critical by the way. In fact, according to this comment it can result in larger payloads when gzipping. So I'm not using WebpackMd5Hash.

On the contrary, I found WebpackMd5Hash to be required when using chunk-manifest-webpack-plugin. Otherwise If only relying on webpack's hash, webpack generates the hash before the chunk-manifest-webpack-plugin runs. This means that the hash for the entry bundle will change whenever a filename for another chunk inside of the manifest changes, even though the manifest is created later.

Ah, good to know that there are several solutions. Thanks all.

Finally, the NamedModulesPlugin and manifest solution works corretly. Thanks!

Setting up a manifest helps with JavaScript a lot. The thing is, if I'm using ExtractTextPlugin and try to alter CSS, it invalidates my JavaScript as well. Here's more info.
Has anyone figured out an approach that works with CSS assets?

I just confirmed that problem: changing the CSS gives a new hash to the main chunk. Not ideal.

I figured out the problem. Given the JS and CSS belonged to the same chunk, altering CSS somehow obviously changed the chunk -> both JS and CSS hash changed as a result. I realized that in my case it was possible to define a separate chunk for the CSS through a separate entry like this:
entry: {
  ...
  style: [
    'purecss',
    'highlight.js/styles/github.css',
    'react-ghfork/gh-fork-ribbon.ie.css',
    'react-ghfork/gh-fork-ribbon.css',
    './demo/main.css',
    './style.css'
  ]
}

It will generate an extra JS file given it's an entry, but given it generates a chunk of its own, we avoid the problem effectively. Obviously you'll hit the original problem again if you refer to CSS in any way from your JS code. So this solution doesn't scale to more complicated cases.

For inlining, you may also use webpack-path-rewriter. It's not in the docs yet, but you can do this (assuming that manifest is located in manifest.json):
<html><body>
...
<script>[[ INLINE(manifest.json) ]]</script>
...
</body></html>

Right now the solution seems to be to use the NamedModulesPlugin, and inject the contents of the manifest chunk into your html. But as recently mentioned, this is only a partial solution as it doesn't handle changes to css.
Will this scenario be made easier / working in webpack 2?

Right now the solution seems to be to use the NamedModulesPlugin, and inject the contents of the manifest chunk into your html. But as recently mentioned, this is only a partial solution as it doesn't handle changes to css.

The document about NamedModulesPlugin is really simple. Is there some detail information?

Have this bug fixed?

I have found that webpack-md5-hash produces hashes that are based solely on the relevant bundle. The vendor bundle hash does not change when the app is edited and recompiled.
Here is my setup: https://gist.github.com/d4goxn/37be7b185cdf4ac28cbb.

Have this bug fixed?

@hanai In fact, I think it's not really a bug. Follow the official sample, you'll solve your problem.
In fact, chunks communicate by webpackJsonp , which requires a helper  (manifist, built-in module) to offer the module's meta information.
If any chunk treated as entrypoint, the manifist will be pack into it.
The sample config shows that you should configure manifist as a chunk.

I'm using the webpack-md5-hash solution which for my problem was ideal:

generating consistent hashes based on the content for app and vendors separately
manually generate a manifest with something like this
use the manifest in my node server to generate the proper html with correct js bundle resource uri

I'm looking forward for webpack 2 to solve this in a more elegant way and possibly start doing finer (and automatic :pray:) chunks

When i use
new webpack.optimize.CommonsChunkPlugin({ names: ['vendor', 'manifest'] })

as described in https://github.com/webpack/webpack/tree/master/examples/chunkhash i end up with a manifest that errors out:
Uncaught TypeError: Cannot read property 'call' of undefined

@danilobuerger, I was encountering that error when I was using the experimental
new webpack.NamedModulesPlugin()

plugin.  Removing that plugin seemed to resolve my issue.

@BuffaloBuffalo not using that plugin, still getting the error.

@danilobuerger, did you use HtmlWebpackPlugin?
If yes, try setting chunksSortMode: 'dependency' in plugin options.
I found that Uncaught TypeError: Cannot read property 'call' of undefined throws when webpack runtime can not load a module.
I got this error when HtmlWebpackPlugin generated next HTML:
<script src="manifest.d41d8cd98f00b204e980.js"></script>
<script src="app.69df06390d496eccbf81.js"></script>
<script src="vendor.2dfc265ff285546a8822.js"></script>

app requires some module from vendor, but it was not loaded yet.

Try to disable the DedupePlugin @44px @danilobuerger ?
I found that plugin is incompatible with CommonChunkPlugin&NamedModulesPlugin

@44px Excellent catch, thank you!
So to anybody else having that problem:
If you use chunkhash with vendor & manifest and you use HtmlWebpackPlugin, set chunksSortMode: 'dependency'.
@airwin i didn't use NamedModulesPlugin, see @44px comment for a fix to my problem.

@airwin @BuffaloBuffalo When using the NamedModulesPlugin i have no problem with still using the DedupePlugin.

can you give a try to add children: true to commmon chunk plugin like:
new webpack.optimize.CommonsChunkPlugin({
name: "vendor",
children: true
})

can you give a try to add children: true to commmon chunk plugin like:
new webpack.optimize.CommonsChunkPlugin({
name: "vendor",
children: true
})

Following the official example is what worked for me (have to split the manifest out from the common chunk). Thanks @renaesop.
Also, I had to take out "children: true" otherwise vendor chunks were being included in my main application file as well as the vendor chunk. I found running "webpack --display-chunks --display-modules" helpful until I got all third party stuff being split into the vendor chunk.

I can't seem to find the magic combination to get this working...
The closest I got is with @kevinrenskers solution: it solves the problem of the manifest being included in vendor.js, but the creation of the manifest means the start of vendor.js now looks something like this: webpackJsonp([29,30],{...})
The 29 and 30 are indices I believe, so if I add another code split in my app, these shuffle to 30,31 and the hash changes.
Has anyone experienced this issue and found a solution/workaround?

I haven't been able to make it completely work with any of the solutions posted here. It's gotten better though with using chunk-manifest-webpack-plugin to extract manifest to a separate file.
After all this I decided to change these hashes using a separate script rather than webpack. Contents of the file are the same for me and my colleagues so I wrote a simple script that renames the files from <entry_point>.js to <entry_point>.<md5hash>.js. We rename the files in the manifest as well so that they match. This is done as part of the build process and so far it works way better.

@DawidJanczak So do you hash the asset yourself based on the file content? If so, how do you get around the fact that the indices of modules change when adding new code splits (which can result in the file contents changing)?

I don't unfortunately, but they only change on seldom occasions for me (e.g. adding an entry point). Even so they end up the same for me and my colleagues anyway and this was the most important bit for us.
This is all assuming your Node version is the same (important). I'm also using OccurenceOrderPlugin which I assume helps a bit as well.

Ah, no probs. I think I've found a solution for our use case. We add code splits quite frequently, which kept invalidating the vendor.js hash. I've fixed it now using records:
module.exports = {
    ...
    recordsPath: path.resolve(__dirname, '.webpack-records.json')
    ...
};

I didn't spot this before because there doesn't seem to be much documentation on it.
This means the module IDs are now consistent between builds, and so the vendor.js hash is consistent.
This was the gist that pointed me in the right direction: https://gist.github.com/sokra/ff1b0290282bfa2c037bdb6dcca1a7aa

Works like a charm @drew-walker, thanks!

@drew-walker, have you tried to use webpack.NamedModulesPlugin together with WebpackMd5Hash, ChunkManifestPlugin and webpack.optimize.CommonsChunkPlugin? This is the combination that worked for me, and it requires no manual renaming of files or storing state between builds.
You can also split Webpack runtime into a separate chunk instead of using ChunkManifestPlugin.

Some loaders that produce source maps use absolute links to these maps in code. Then chunkhash depends on full system path.

This config does not overwrite the common chunk for me in production build. The main app chunk gets overwritten when required:
const { optimize } = require('webpack');
const { resolve } = require('path');
const { dependencies } = require('./package.json');
const WebpackMd5Hash = require('webpack-md5-hash');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = env => {
  return {
    context: resolve(__dirname, './app'),
    entry: {
      app: './index.jsx',
      common: Object.keys(dependencies)
    },
    output: {
      filename: '[name].[chunkhash].bundle.js',
      path: resolve(__dirname, './dist'),
      pathInfo: !env.prod,
      chunkFilename: '[chunkhash].js'
    },
    devtool: env.prod ? 'source-map' : 'eval',
    module: {
      loaders: [
        {
          test: /\.css$/,
          loaders: [
            'style',
            'css'
          ]
        },
        {
          test: /\.(js|jsx)$/,
          exclude: /node_modules/,
          loaders: [
            'babel-loader'
          ]
        }
      ],
    },
    plugins: [
      new WebpackMd5Hash(),
      new HtmlWebpackPlugin({
        template: './index.html'
      }),
      new optimize.CommonsChunkPlugin({
        name: 'common',
        filename: 'common.[chunkhash].bundle.js'
      })
    ],
    resolve: {
      extensions: ['', '.js', '.jsx'],
      modules: [
        resolve('./app'),
        'node_modules'
      ]
    },
    devServer: {
      contentBase: './app'
    }
  };
};

Wow this is a can of worms. I'm having this problem when trying to build a project as a dependency. Works fine when not a dependency, but calling webpack --config [webpack.prod].conf.js --progress --profile --colors --display-error-details --display-cached --bail as a postinstall script always returns an error like:
project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/Compiler.js:204 		if(err) return callback(err);                  ^ TypeError: Cannot read property 'hash' of undefined     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/html-webpack-plugin/lib/compiler.js:73:31     at Compiler.<anonymous> (project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/Compiler.js:204:18)     at Compiler.<anonymous> (project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/Compiler.js:395:18)     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/tapable/lib/Tapable.js:99:11     at Compilation.<anonymous> (project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/Compilation.js:433:11)     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/Compilation.js:414:13     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/Compilation.js:329:11     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:52:16     at done (project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:241:17)     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:44:16     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/Compilation.js:329:11     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:52:16     at done (project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:241:17)     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:44:16     at errorAndCallback (project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/Compilation.js:200:5)     at errorOrWarningAndCallback (project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/Compilation.js:225:13)     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/Compilation.js:229:12     at onDoneResolving (project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/NormalModuleFactory.js:29:20)     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/lib/NormalModuleFactory.js:114:22     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:726:13     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:52:16     at done (project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:241:17)     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:44:16     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:723:17     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:167:37     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:52:16     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:361:13     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:52:16     at done (project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:241:17)     at project-api-nodejs/node_modules/project-admin-ng2admin/node_modules/webpack/node_modules/async/lib/async.js:44:16
Looking for a reason/solution

This was resolved. ended up being related to paths:

removed --profile --colors --display-error-details --display-cached --bail from the command.
changed webpack config to build in the correct directory. - there was a production and a dev config for build which were'nt the same.

Not sure if this was helpful or more confusing - is resolvable.

take hash
script.src = __webpack_require__.p + "" + chunkId + "." + ({"0":"cards","2":"import","3":"pc"}[chunkId]||chunkId) + "_" + {"0":"44d502a39f0cecd64dd2","2":"219b75fda07da5268c11","3":"7ee21f78f624764b86a8"}[chunkId] + ".js";
no hash
script.src = __webpack_require__.p + "" + chunkId + "." + ({"0":"cards","2":"import","3":"pc"}[chunkId]||chunkId) + "_" + {"0":"44d502a39f0cecd64dd2","2":"219b75fda07da5268c11","3":"7ee21f78f624764b86a8"}[chunkId] + ".js";
change reason

mark

So the solution is to use this approach? https://github.com/webpack/webpack/tree/master/examples/chunkhash

@jnwelzel I think you'll find that, if you're only using WebpackMd5Hash, your vendor.js hash will still change if you add a new code split, because the chunk manifest will still be inside your vendor.js file.

@drew-walker thanks for the heads up, but if I plan on only using those two chunks (vendor.js and application.js for example) I should be fine?

@jnwelzel no, you also should to extract "chunk manifest" from vendors bundle and use NamedModulesPlugin or HashedModuleIdsPlugin to guarantee module ids will not change between builds.
Anyway, you don't need to use webpack-md5-hash plugin.

I agree with @renaesop
And notice the official sample in the index.html "manifest.[chunkhash].js" code has been inject to html,no a script tag
How to do that ?

@qbaty you can use https://github.com/ampedandwired/html-webpack-plugin for that

@somebody32 I did not see a way that html-webpack-plugin can inject inline script code

In webpack config:
    new HtmlWebpackPlugin({
      excludeChunks: ['manifest'],
      templateContent: function(templateParams, compilation) {
        Object.keys(compilation.assets).forEach((key) => {
          if (key.indexOf('manifest.') === 0) {
            if (compilation.assets[key].children) {
              templateParams.chunkManifest = compilation.assets[key].children[0]._value;
            }
            delete compilation.assets[key];
          }
        });

        var indexTemplate = fs.readFileSync(path.resolve('./src/index.html'), 'utf8');
        var tmpl = require('blueimp-tmpl').tmpl;

        return tmpl(indexTemplate, templateParams);
      },
      minify: {
        removeComments: true,
        collapseWhitespace: true
      }
    }),

In index.html:
{% if(o.chunkManifest) { %}
<script>{%#o.chunkManifest%};</script>
{% } %}

@qbaty https://github.com/ampedandwired/html-webpack-plugin/tree/master/examples/inline

@qbaty https://github.com/xiaoyann/webpack-react-redux-es6-boilerplate/blob/master/build/webpack.config.js#L184-L203

@xiaoyann 👍

@somebody32 @kevinrenskers @xiaoyann
Thank you guys, got it.

Does anyone have HashedModuleIdsPlugin working along side of using CommonsChunkPlugin to generate both a 'vendor' file and an manifest?
The manifest's dictionary is indexed via numeric module ID:
{"0":"24b1b62d0787b7ea0c1b","1":"11ab7bdb5afd13897a5f","2":"a7d56a2454e7ad641b90"}

Whereas the entry chunks do stuff like: __webpack_require__("/sXU");

@drew-walker   can you post your webpack config code, i'm having the same issue. If i add a new import in my app file of already used module, the vendor file also changes. Same thing occurs when i remove an import of a module that is already being used in another component. I'm using webpack": ^1.13.2.    My current webpack config looks like the following:   import webpack from 'webpack'
import path from 'path'
import HtmlWebpackPlugin from 'html-webpack-plugin'
import autoprefixer from 'autoprefixer'
import ExtractTextPlugin from 'extract-text-webpack-plugin'
import SWPrecacheWebpackPlugin from 'sw-precache-webpack-plugin'
import CopyWebpackPlugin from 'copy-webpack-plugin'
import pkg from './package.json'
import CleanWebpackPlugin from 'clean-webpack-plugin'
import InlineManifestWebpackPlugin from 'inline-manifest-webpack-plugin'
import WebpackMd5Hash from 'webpack-md5-hash'

const LAUNCH_COMMAND = process.env.npm_lifecycle_event

const isProduction = LAUNCH_COMMAND === 'production'
process.env.BABEL_ENV = LAUNCH_COMMAND

const PATHS = {
  root: path.join(__dirname),
  app: path.join(__dirname, 'app'),
  build: path.join(__dirname, 'dist')
}

// inserts link and scripts dependcies in to the generated index.html
const HTMLWebpackPluginConfig = new HtmlWebpackPlugin({
  template: PATHS.app + '/index.html',
  filename: 'index.html',
  inject: 'body'
})

// removed dist directory before run start or run production
const SharedPlugin = new CleanWebpackPlugin([PATHS.build], {
  root: PATHS.root,
  verbose: true,
  dry: false
})

// generates vendor js file (code splitting)
const DevelopmentPlugin1 = new webpack.optimize.CommonsChunkPlugin({
  name: 'vendor',
  minChunks: Infinity,
  filename: 'vendor.js'
})

const productionPlugin = new webpack.DefinePlugin({
  'process.env': {
    NODE_ENV: JSON.stringify('production')
  }
})

const productionPlugin1 = new WebpackMd5Hash()

// copies files at runtime
const productionPlugin2 = new CopyWebpackPlugin([
      { from: PATHS.app + '/manifest.json' },
      { from: PATHS.app + '/media/images' },
      { from: PATHS.app + '/media/favicon.ico' },
      { from: PATHS.app + '/service-worker-registration.js' }
])

// generates vendor js file (code splitting)
const productionPlugin3 = new webpack.optimize.CommonsChunkPlugin({
  names: ['vendor', 'manifest']
})

const productionPlugin3A = new InlineManifestWebpackPlugin({
  name: 'webpackManifest'
})

// service worker generation
const productionPlugin4 = new SWPrecacheWebpackPlugin(
  {
    cacheId: pkg.name, // unique cacheID
    filename: pkg.name + '-service-worker.js', // filename for the generated sw file
    handleFetch: true, // set to false for DEV Server and Change to True for Production
    stripPrefix: 'C:/Users/jasan/Downloads/duckr/dist/'
    // runtimeCaching: [{
    //   urlPattern: 'https://duckr-201b9.firebaseapp.com/feed',
    //   handler: 'networkFirst'
    // }]
  }
)

// minifies all build code
const productionPlugin5 = new webpack.optimize.UglifyJsPlugin({
  compressor: {
    warnings: false
  }
})

const productionPlugin6 = new ExtractTextPlugin('style.css') // extracts seperate css file for caching instead of inline styles

const productionPlugin7 = new webpack.optimize.DedupePlugin() // deduplicates equal or similar files

const productionPlugin8 = new webpack.optimize.OccurrenceOrderPlugin()

const base = {
  entry: {
    app: [
      'babel-polyfill',
      PATHS.app
    ],
    vendor: Object.keys(pkg.dependencies)
  },
  postcss: [ autoprefixer({ browsers: ['last 2 versions'] }) ],
  resolve: {
    root: path.resolve('./app')
  }
}

const developmentConfig = {
  devtool: 'cheap-module-inline-source-map',
  output: {
    path: PATHS.build,
    filename: 'index_bundle.js'
  },
  module: {
    loaders: [
      {test: /\.js$/, exclude: /node_modules/, loader: 'babel-loader'},
      {test: /\.css$/, loader: 'style!css?sourceMap&modules&localIdentName=[name]__[local]___[hash:base64:5]&importLoader=1!postcss'}
    ]
  },
  devServer: {
    contentBase: PATHS.build,
    historyApiFallback: true,
    hot: true,
    inline: true,
    progress: true
  },
  plugins: [HTMLWebpackPluginConfig, new webpack.HotModuleReplacementPlugin(), DevelopmentPlugin1, SharedPlugin]
}

const productionConfig = {
  devtool: 'cheap-module-source-map',
  output: {
    path: PATHS.build,
    filename: '[name].[chunkhash].js',
    // This is used for require.ensure. The setup
    // will work without but this is useful to set.
    chunkFilename: '[chunkhash].js'
  },
  module: {
    loaders: [
      {test: /\.js$/, exclude: /node_modules/, loader: 'babel-loader'},
      { test: /\.css$/, loader: ExtractTextPlugin.extract('css?modules&localIdentName=[name]__[local]___[hash:base64:5]&importLoader=1!postcss') }
    ]
  },
  plugins: [HTMLWebpackPluginConfig, productionPlugin, SharedPlugin, productionPlugin1, productionPlugin2, productionPlugin3, productionPlugin3A, productionPlugin4, productionPlugin5, productionPlugin6, productionPlugin7]
}

const records = {recordsPath: path.resolve(__dirname, PATHS.build + '/webpack.records.json')}

export default Object.assign({}, base, records, isProduction === true ? productionConfig : developmentConfig)

I think most people think this is a bug as they are ignorant concept of manifest. Webpack injects its own runtime and that changes every time. To implement this there is an example. I have also implemented https://github.com/rohitlodha/html-webpack-inline-chunk-plugin to help inline.

How to keep you vendor don't change?
my webpack.config entry is:
entry{
   vendor:['react', 'redux'],
   app: './aap'
}

plugin is:
new optimize.CommonsChunkPlugin('vendor');

So use 'code-spliting'add a chunk, the vendor and app is all change.
and a change the entry to:
entry{
   a_vendor:['react', 'redux'],
   z_app: './aap'
}

add a chunk again, The vendor is not change!  joke

According to this post, the simplest solution may be:
new webpack.optimize.CommonsChunkPlugin({
  names: ['vendor', 'mainifest'] // <---- only add 'mainifest', no more
})

@kenberkeley If you bundle manifest within vendor, changes made to app bundle will lead to changes to manifest that will invalidate vendor bundle too, correct. That's why it's important to extract it to a file of its own or inline it within HTML (html-webpack-plugin).

@bebraw
add some code to app and build again, see the difference:
( vendor still with the same hash )

@kenberkeley That was my point, yeah. I've written about the topic here.

@bebraw if you use code-spliting add a new chunk, you will find the 'manifest' is useless

mark

I've used only webpack-md5-hash plugin and looks like it solves the issue: the hash of common bandle wasn't changed.
I've separated manifest file to check it content and it has valid hashes every time I update some js file... but hash of manifest file doesn't changed.

@bebraw I've read your post, but I've just added manifest to names.

It seems like everyone here wants the same but there's no simple way to tell webpack :(.

webpack-md5-hash works for me

@all
Just take a look webpack-stable-module-id-and-hash: To provide stable module id and reliable content chunkhash.

@zhenyong is correct, be careful with webpack-md5-hash.

So I'm curious, isn't recordsPath + extracting manifest into separate enough to solve this? I though @sokra fixed problem when cache isn't updating on dependencies change, did he?

So I'm curious, isn't recordsPath + extracting manifest into separate enough to solve this?

AFAIK this should work.

@sokra @NekR
recordsPath + extracting manifest should works.
I just personally dont like check in extra file. ^_^

Any working and robust solution to this problem yet? It's been months, none of the solutions have worked for me.... I even tried writing my own hashing plugin for webpack but seems like there's an issue with the nodejs crypto module. It creates different hashes on different machines.

@paramsingh88 this worked perfectly for me: https://github.com/kossnocorp/assets-webpack-plugin
well, you have to apply the following PR which isn't merged yet:
https://github.com/kossnocorp/assets-webpack-plugin/pull/56
that adds support for source maps.
Also it uses @mattkrick 's technique to create an empty chunk with just the bootstrap code:
<EMAIL_ADDRESS>That likely is your one remaining problem. The chunkhash will change while vendor.js still has the bootstrap code in it, since the bootstrap code changes any time any of the chunks change since it references them. So by removing it from vendor.js it becomes stable.
In short, all you have to do is add another entry point in the names array (and no actual entry point for it has to exist):
new webpack.optimize.CommonsChunkPlugin({
        names: ['vendor', 'manifest'],

This works fine without having to use any other plugins. The difference is this vendor bundle is auto generated based on the node_modules directory. If you manually declare it as an entry then the vendor bundle chunkhash will change even though the md5 output does not ( as OP's issue shows ).
// Modified from OP's repo
module.exports = {
  context: path.join(__dirname, 'src'),
  entry: {
    main: ['./entry.js'],
  },

  output: {
    path: out,
    filename: '[name].[chunkhash].js',
    chunkFilename: '[chunkhash].js'
  },

  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor.js',
      minChunks: ({resource}) => /node_modules/.test(resource)
    }),

    new webpack.optimize.CommonsChunkPlugin({
      name: 'manifest.js',
    }),
    // ...
  }
  // ...
}

I'm using the following config setup and feel good about it. Hashes change when it should. I checked that if ONLY indexes of chunks in files have been changed, hashes still stay the same (@drew-walker earlier in this issue assumed that hashes would change after that kind of changes in webpackJsonp functions). Moreover, hashes didn't change even after resulting files replace "_webpack_require_(old_index)" by "_webpack_require_(new_index)" (I changed order purposely). CSS files also act correct.
So may be it's not that bad? Or I just didn't get where the problem is...
Here's my config:
const webpack = require("webpack");
const path = require('path');
const ExtractTextPlugin = require('extract-text-webpack-plugin');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const WebpackMd5Hash = require('webpack-md5-hash');

module.exports = {

  entry: {
    pageA: './src/pagea.js',
    pageB: './src/pageb.js',
    vendor: './src/vendor.js'
  },

  cache: true,
  debug: true,
  devtool: 'source-map',

  module: {
    loaders: [{
      test: /\.css/,
      loader: ExtractTextPlugin.extract( "style", "css?sourceMap")
    }]
  },

  plugins: [
    new ExtractTextPlugin('styles.[contenthash].css'),

    new webpack.optimize.CommonsChunkPlugin({
      names: [ 'commons', 'vendor', 'manifest'],
      minChuncks: Infinity
    }),

    new HtmlWebpackPlugin({
      template: './src/index.html',
      hash: false,
      inject: 'body',
      cashe: true
    }),

    new WebpackMd5Hash()
  ],

  output: {
    publicPath: "./",
    path: path.join(__dirname, "dist"),
    filename: "[name].[chunkhash].js",
    chunkFilename: "[name].[chunkhash].js"
  }
};

@GProst, thanks for this. I was finding that if for some reason, the _webpack_require_(old_index) got replaced by _webpack_require_(new_index), the hashes were changing. Taking cue from your config file, I started using the webpack-md5-hash and it has seemed to fix it. Have done a couple of tests and they have come out to be good. Will post again if this changes.

I'm desperate, if I try to use the "working" solution, I get `cannot use [chunhash] for chunk in [name]-[chunkhas] use [chunk] instead.
When I use [chunk] instead, both manifest and vendors file are generated with the same hash (yet have different sizes), and when I change app, this id changes on both. Any idea please?
new webpack.optimize.CommonsChunkPlugin({
    names: 'vendor',
    filename: 'vendor-[id].[hash].js',
    minChunks: ({resource}) => /node_modules/.test(resource)
  }),
  new webpack.optimize.CommonsChunkPlugin({
    name: 'manifest.js',
    filename: 'manifest-[id].[hash].js',
  }),
output: {
    path: buildPath,
    publicPath: '/',
    filename: '[name]-[hash].js',
    chunkFilename: "[name]-[hash].js",
  },

I didn't know this issue was still going. Linking this to the docs issue I created earlier, while looking for a good way to solve long-term hashing:
https://github.com/webpack/webpack.js.org/issues/652

I hope this is helpful to some, I've outlined what I got working for me in this post: https://jeremygayed.com/dynamic-vendor-bundling-in-webpack-528993e48aab#.t08fegesc

@zhenyong solution worked for me.

I used HashedModuleIdsPlugin along with CommonsChunkPlugin for vendor and manifest. Working as expected.

Okay, in our project armor-piercing fix is using HashedModuleIdsPlugin with webpack-chunk-hash
also setup for webpack-chunk-hash should be (https://github.com/alexindigo/webpack-chunk-hash/issues/2)
{
  additionalHashContent: chunk => chunk.id
}

Thanks @GProst. Your solution works for me.

I had a hard time finding a solution here that helped. But this tutorial is great and worked for me: https://medium.com/connect-the-dots/caching-assets-long-term-with-webpack-5ad24a4c39bd#.u1sz47vc1.

Did you all switch to webpack 2 yet?

entry: {
    coursemology: ['babel-polyfill', './app/index'],
    vendor: ['dep1', 'dep2'],
  },
  plugins: [
    new webpack.IgnorePlugin(/__test__/),
    new webpack.optimize.CommonsChunkPlugin({
      names: ['vendor', 'manifest'],
    }),
  ],

We still experiencing this in webpack 2.2.0, above is our config. Any new require in the app code will result in vendor hash changes.

I have the same issue as @allenwq (Webpack 2.2.1), except I tried to switch order app and vendor in entryproperty. I'm getting 3 chunked files: vendor, manifest and app, but every time I change something in app other changes hash too.
...
entry: {
      vendor: [ "moment", "jquery" ],
      app: [ "./src/main.ts" ]
    },

    output: {
      path: path.resolve( __dirname, "build" ),
      publicPath: '',
      filename: "[hash].[name].js"
    },
...
plugins: [
      new webpack.optimize.CommonsChunkPlugin({
        names: [ 'vendor', 'manifest' ],
        minChunks: Infinity
      })
    ]

I'm having this problem too (using Laravel Mix and Webpack 2).

Did you all switch to webpack 2 yet?

Yes

Ok, here's my final config on webpack 2 that seems to work (at least for me):
	  output: {
	      path: path.resolve('./assets/bundles/'),
	      filename: "[name]-[chunkhash].js",
	      chunkFilename: "[name]-[id]-[chunkhash].js"
	  },

No manifest in CommonsChunkPlugin (that seemed misuse of the CommonsChunkPlugin to me).
	        new ExtractTextPlugin({
	        	filename:'[name]-[chunkhash].css',
	        }),
	        new webpack.NamedModulesPlugin(),
	    new ChunkManifestPlugin({
	      filename: "chunk-manifest.json",
	      manifestVariable: "webpackManifest"
	    })

Every file now gets a hash based on its content. This means that all extracted css files have a name based on their content, but also the different js files have a name based on their content.
The important part is: 	      filename: "[name]-[chunkhash].js".
No need for Md5Hash of ChunkHash plugins.

I think the problem has been fixed in the 2.3.3 version. Please checkout this tutorial. It worked for me.
https://webpack.js.org/guides/code-splitting-libraries/

I've struggled a lot with this but this actually seems to work for me: https://webpack.js.org/guides/code-splitting-libraries/

I can confirm that it is working with solution that @danny-andrews showed above. Very important to understand that [hash] applies hash of a webpack build, so every file will have same hash, but [chunkhash] applies hash to every file separately.
So, this is how it works in my config:
output: {
  path: path.resolve( __dirname, "build" ),
  publicPath: '/',
  filename: "js/[name].[chunkhash].js"
},
plugins:[
...
new webpack.NamedModulesPlugin(),
new webpack.optimize.CommonsChunkPlugin( {
    name: [ "vendor", "manifest" ],
    chunksSortMode: "dependency"
} ),
...
]

@lomboboo  Apparently chunksSortMode isn't actually an option for CommonsChunkPlugin? https://github.com/webpack/webpack/blob/master/lib/optimize/CommonsChunkPlugin.js#L16-L24

@tizmagik you're right, just updated it. Anyway, it is working in my setup

Given this ticket is still very active, I'll add this to the list of solutions:
https://medium.com/@schnibl/predictable-long-term-caching-with-webpack-d3eee1d3fa31

It still alive. I can't make it work. Tried everything. Confusing :(

@gabn88 I think your issue with the hashes changing when you add a new entry can be fixed by using NamedChunksPlugin. If that works, I'll add it to my solution. Also, we should add an example for solving this problem to in order to put this ticket to rest once and for all. :)

@zaguini Agreed, it is very confusing. Have you tried the solution I posted. It's the minimal config you need to get it working.

For those interested in using Webpack records to maintain consistent file hashes between builds, I wrote a bit about that here - https://medium.com/@songawee/long-term-caching-using-webpack-records-9ed9737d96f2.

The saga continues...
I followed the official documentation on caching and it (thankfully) works fine. Then I added UglifyJS for tree shaking and compression, the output files themselves changed but the hashes didn't. That was surprising to me, since it can lead to complications (you minify but clients don't receive the new files since hashes don't change.)
Found out that chunkhash with the recommended method does the hashing before any other optimisations (like the ones done by UglifyJS.)
Then I found this: https://github.com/webpack/webpack/issues/4659
The proposed webpack-plugin-hash-output plugin seems to work, it does the hashing on top of the processed output (as far as I can understand) and seems to solve the issue... For now.
It's plugins on top of plugins on top of plugins at this point and I've been burned by this so many times over the years. Just when you think it all works, you change one config and it all crashes and burns until you add yet another plugin. The process is so so brittle.
Maybe this is not the right place but after all these years I'm convinced that this won't get any better, and the design is fundamentally flawed for this type of thing. Are there any commonly used solutions for long term caching outside of webpack? Like using webpack just for the vanilla bundling, and then something else goes through the HTML and linked resources to hash them separately and change the references in files?
In any case, if webpack-plugin-hash-output is the recommended solution now, is it worth adding to the documentation? The current documentation is leading people down a dangerous path (i.e. if they add anything to the plugin chain that processes / changes the files, the hashes won't change and at best people will waste their time diagnosing the issue like I did.)

earslap, I hear what you're saying, but it just reminds me of (https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/).
To answer your question, perhaps the best way to minimize the danger of getting burned by this type of thing, you should cache for a shorter amount of time. That way, if they accidentally cache the non-minimized version, it won't stay cached forever.
Sorry, I can't offer you more, but at least it's better than nothing. Patches are certainly welcome.

Oh no, I wasn't trying to put a blame on anyone involved with this project, sorry if my frustration made it sound like this way.
I still think this is a fundamental design issue with the way webpack is architected. Brightest minds working on this deceptively simple issue for 2.5+ years, coming up with various solutions but none sticks. I don't know much about the internals of webpack but I assume something in there makes this extremely tricky.
If you strip all my frustrations from my earlier post, the meat should have been this: The documented method of cache busting (which I think summarises a happy path gathered from the discussions in this thread the past 2.5 years) will not work if any other plugin modifies the files along the way due to a config change, the hashes won't change. If my understanding is correct, there is a proposed solution that tries to fix this (here: https://github.com/webpack/webpack/issues/4659). Is this recommended, and if so should that be added to the documentation?

Just named the vendor can solve this problem 😆
code:
···
new webpack.optimize.CommonsChunkPlugin({
      names: 'vendor',
      minChunks: Infinity,
      filename: 'vendor.bundle.js',
 })
···

Anyone else coming here needing a solution, just create your own md5 hash.
const crypto = require('crypto');
const vendorList = [/* list of vendor files */];
const vendorHash = crypto.createHash('md5').update(vendorList.join('')).digest('hex');

Use vendorHash in the vendor filename options:
filename: vendor.${vendorHash}.js`

Regarding my comment above - that won't work as the bundle is referenced in the vendor file.

@earslap if your cache does not invalidate when the contents of a file changes than perhaps you should look into fixing that.
Personally, I don't understand the obsession with using hashes in file names. There are far more simple, and easy to use methods of versioning files, and cache busting. This really isn't even an issue in webpack's wheel house to solve for you.
I feel like this is not something the webpack maintainers should worry about. This is not really webpack's role to fill.

@michaelBenin can you please explain a little bit more why custom vendor hash will not work. I mean what will happen if bundle had changed, but vendor file still referencing the old bundle. Will it cause any errors?
I was thinking of using it because all other approaches end with different hashes after CI builds, even if vendors were not changed. So want to know what caveats are here.

@maksimsemenov ~
First off we didn't get this working as intended, this issue is still open.
Basically we found that the vendor file has a reference of the app.js and that caused an error breaking JS.

is this still happening for webpack 4?

To a certain extent, webpack 4 improved this situation, at least reducing the frequency of vendor hash changes, but the problem still exists.
See full code here
First,npm run build, output

If you just modify src/client.js, the vendor file's hash will remain unchanged unless your modified part changes the count of split chunks.
Like, comment one async import statement in src/client.js:
import React from 'react';

import { render } from 'react-dom';

// import('./App');

Then npm run build would output

Why? Because the vendors~app file still has a chunkId.
// head line in vendor-app file. This chunk Id is 1.
(window["webpackJsonp"] = window["webpackJsonp"] || []).push([[1],{
......

// installedChunks in app.js

Maybe we need a special way to treat initial chunk. Treat that they are already installed without checking ?

@kevinrenskers
I close this issue due with a very large number of questions/posts with very difference problems. t's also hard to understand exactly what the problem - in the configuration or it's a real bug. Also please read https://medium.com/webpack/predictable-long-term-caching-with-webpack-d3eee1d3fa31 (some steps no needs because it is already fixed in webpack). Feel free create new issue with minimum reproducible test repo.
In short ways:
webpackConfig.output = {
    chunkFilename: '[name]-[contenthash].chunk.js',
    filename: '[name]-[contenthash].js'
};

webpackConfig.plugins = [
   // ------------------------------------
    // Long Term Caching
    // ------------------------------------
    // More information https://medium.com/webpack/predictable-long-term-caching-with-webpack-d3eee1d3fa31
    new webpack.NamedChunksPlugin(chunk => {
      if (chunk.name) {
        return chunk.name;
      }

      // eslint-disable-next-line no-underscore-dangle
      return [...chunk._modules]
        .map(m =>
          path.relative(
            m.context,
            m.userRequest.substring(0, m.userRequest.lastIndexOf("."))
          )
        )
        .join("_");
    }),
    new webpack.HashedModuleIdsPlugin()
];


display-manager.service fails to start #2

Describe the bug
After booting, the display manager doesn't come up with NixOS 19.09. There's another posted issue with the same symptom but which seems to be a different problem: https://github.com/NixOS/nixpkgs/issues/62383
To Reproduce

Use the following configuration.nix: https://gist.github.com/mzabani/ce02eda44f1812097975c2af4384c8f0
Use the following nix channel and run nixos-rebuild switch --upgrade from a 18.09 NixOS system.

# nix-instantiate --eval -E '(import <nixpkgs> {}).lib.version'
"19.09.1320.4ad6f1404a8"

Boot into the new system, run systemctl status display-manager.service:

● display-manager.service - X11 Server
   Loaded: loaded (/nix/store/sw9hdni0zvasc49hin91g91araydmc7p-unit-display-manager.service/display-manager.service; linked; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2019-11-30 10:44:50 -03; 49s ago
  Process: 904 ExecStartPre=/nix/store/whfc2qz651zbvzdph51qjqajkncqg471-unit-script-display-manager-pre-start (code=exited, status=0/SUCCESS)
  Process: 906 ExecStart=/nix/store/qj14p4v0xi21zlsbcndxpp64dwyjddp0-unit-script-display-manager-start (code=exited, status=1/FAILURE)
 Main PID: 906 (code=exited, status=1/FAILURE)
       IP: 0B in, 0B out
      CPU: 56ms

Nov 30 10:44:50 nixos systemd[1]: display-manager.service: Service RestartSec=200ms expired, scheduling restart.
Nov 30 10:44:50 nixos systemd[1]: display-manager.service: Scheduled restart job, restart counter is at 3.
Nov 30 10:44:50 nixos systemd[1]: Stopped X11 Server.
Nov 30 10:44:50 nixos systemd[1]: display-manager.service: Start request repeated too quickly.
Nov 30 10:44:50 nixos systemd[1]: display-manager.service: Failed with result 'exit-code'.
Nov 30 10:44:50 nixos systemd[1]: Failed to start X11 Server.

Expected behavior
The display manager should start after booting without issues.
Metadata
# nix run nixpkgs.nix-info -c nix-info -m
 - system: `"x86_64-linux"`
 - host os: `Linux 4.19.84, NixOS, 19.09.1320.4ad6f1404a8 (Loris)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3`
 - channels(mzabani): `"nixos-18.09.2574.a7e559a5504, nixpkgs-19.09pre183693.baa75f0c25a"`
 - channels(root): `"nixos-19.09.1320.4ad6f1404a8, nixpkgs-20.03pre202154.58fb23f72ad"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

You can get better logs with journalctl -b -u display-manager.

Sorry for taking so long, and thanks for the tips. This is the output of journalctl -b -u display-manager:
-- Logs begin at Mon 2017-10-23 19:08:02 -02, end at Wed 2019-12-11 17:25:10 -03. --
Dec 11 17:24:40 nixos systemd[1]: Starting X11 Server...
Dec 11 17:24:40 nixos systemd[1]: Started X11 Server.
Dec 11 17:24:40 nixos systemd[1]: display-manager.service: Main process exited, code=exited, status=1/FAILURE
Dec 11 17:24:40 nixos systemd[1]: display-manager.service: Failed with result 'exit-code'.
Dec 11 17:24:40 nixos systemd[1]: display-manager.service: Service RestartSec=200ms expired, scheduling restart.
Dec 11 17:24:40 nixos systemd[1]: display-manager.service: Scheduled restart job, restart counter is at 1.
Dec 11 17:24:40 nixos systemd[1]: Stopped X11 Server.
Dec 11 17:24:40 nixos systemd[1]: Starting X11 Server...
Dec 11 17:24:40 nixos systemd[1]: Started X11 Server.
Dec 11 17:24:40 nixos systemd[1]: display-manager.service: Main process exited, code=exited, status=1/FAILURE
Dec 11 17:24:40 nixos systemd[1]: display-manager.service: Failed with result 'exit-code'.
Dec 11 17:24:41 nixos systemd[1]: display-manager.service: Service RestartSec=200ms expired, scheduling restart.
Dec 11 17:24:41 nixos systemd[1]: display-manager.service: Scheduled restart job, restart counter is at 2.
Dec 11 17:24:41 nixos systemd[1]: Stopped X11 Server.
Dec 11 17:24:41 nixos systemd[1]: Starting X11 Server...
Dec 11 17:24:41 nixos systemd[1]: Started X11 Server.
Dec 11 17:24:41 nixos systemd[1]: display-manager.service: Main process exited, code=exited, status=1/FAILURE
Dec 11 17:24:41 nixos systemd[1]: display-manager.service: Failed with result 'exit-code'.
Dec 11 17:24:41 nixos systemd[1]: display-manager.service: Service RestartSec=200ms expired, scheduling restart.
Dec 11 17:24:41 nixos systemd[1]: display-manager.service: Scheduled restart job, restart counter is at 3.
Dec 11 17:24:41 nixos systemd[1]: Stopped X11 Server.
Dec 11 17:24:41 nixos systemd[1]: display-manager.service: Start request repeated too quickly.
Dec 11 17:24:41 nixos systemd[1]: display-manager.service: Failed with result 'exit-code'.
Dec 11 17:24:41 nixos systemd[1]: Failed to start X11 Server.

I tried enabling gdm too, but it also failed, although in a different way:
journalctl -b -u display-manager
-- Logs begin at Mon 2017-10-23 19:08:02 -02, end at Wed 2019-12-11 17:31:31 -03. --
Dec 11 17:30:46 nixos systemd[1]: Starting X11 Server...
Dec 11 17:30:46 nixos systemd[1]: Started X11 Server.
Dec 11 17:30:46 nixos gdm[856]: Child process -872 was already dead.
Dec 11 17:31:17 nixos gdm[856]: Child process -1215 was already dead.
Dec 11 17:31:21 nixos gdm[856]: Child process -1223 was already dead.

I'm having exactly the same issue on a new machine (no upgrade involved).
On Crtl-Alt-F7 i see a cursor blinking continuously (this is as soon as I tried to systemctl start display-manager.server), while on Ctrl-Alt-F1 I am able to see these logs:
Starting X11 Server...
Started X11 Server
display-manager.service: Main process exited, code=exited, status=1/FAILURE
display-manager.service: Failed with result 'exit-code'.
display-manager.service: Scheduled restart job, restart counter is at 1.
Stopped X11 Server
Starting X11 Server...
...

If you don't have a display manager - I think that setting services.xserver.desktopManager.xterm.enable = true may fix this.

Thanks @matthewbauer.
I tried it with combinations of enabled/disabled desktopManager.xterm and enabled/disabled displayManager.service, with running nix-channel --update before nixos-install, but the result is still the same, unfortunately.

Sharing some information I learned while trying to get my setup working, here. I don’t have a working system yet, I’m still trying to get it to work.

On version 19.09, amdgpu-pro errors out with abiCompat, specifically that it is compatible with xserver 1.19 and not 1.20. (1.20 is the default on 19.09 at the moment)

Using amdgpu, the OS gets installed alright, but X11 server exits with an error upon trying to startx. Logs below (~/.xorg.log):

[...]
[   856.488] (==) Using config file: "/etc/X11/xorg.conf"
[   856.489] (==) Using config directory: "/etc/X11/xorg.conf.d"
[   856.489] (==) Using system config directory "/nix/store/z927pbwkkwagg0lx4imiyfip1jkxpy5j-xorg-server-1.20.5/share/X11/xorg.conf.d"
[   856.489] (==) ServerLayout "Layout[all]"
[   856.489] (**) |-->Screen "Screen-amdgpu[0]" (0)
[   856.489] (**) |   |-->Monitor "<default monitor>"
[   856.489] (**) |   |-->Device "Device-amdgpu[0]"
[   856.489] (==) No monitor specified for screen "Screen-amdgpu[0]".
        Using a default monitor configuration.
[   856.489] (**) |-->Screen "Screen-radeon[0]" (1)
[   856.489] (**) |   |-->Monitor "<default monitor>"
[   856.489] (**) |   |-->Device "Device-radeon[0]"
[   856.489] (==) No monitor specified for screen "Screen-radeon[0]".
        Using a default monitor configuration.
[   856.489] (**) Option "DontZap" "on"
[   856.489] (**) Option "AllowMouseOpenFail" "on"
[   856.489] (==) Automatically adding devices
[   856.489] (==) Automatically enabling devices
[   856.489] (==) Automatically adding GPU devices
[   856.489] (==) Max clients allowed: 256, resource mask: 0x1fffff
[   856.489] (**) FontPath set to:
[...]
[   856.494] (II) AMDGPU(0): [KMS] drm report modesetting isn't supported.
[   856.494] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[   856.494] (EE) Screen 0 deleted because of no matching config section.
[   856.494] (II) UnloadModule: "amdgpu"
[   856.494] (EE) Device(s) detected, but none match those in the config file.
[   856.494] (EE)
Fatal server error:
[   856.494] (EE) no screens found(EE)
[   856.494] (EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
[   856.494] (EE) Please also check the log file at "/home/aniketd/.xorg.log" for additional information.
[   856.494] (EE)
[   856.495] (EE) Server terminated with error (1). Closing log file.

I tried to be smart with a /etc/X11/xorg.conf.d/20-radeon.conf, with the following contents:

Section "Device"
        Identifier "RADEON HDMI"
        Driver "amdgpu"
        Screen 0
EndSection

Section "Screen"
        Identifier "Screen 0"
        Device "RADEON HDMI"
EndSection

But my hunch is that this didn’t get picked up, because it led to no difference in the .xorg.log output.
note: You see “amdgpu” and “radeon” both in the generation of the xorg configuration most likely because I used videoDrivers = [ "amdgpu" "radeon" ]; (although I’m not super sure about this)
I don’t know what I should do next.
[ the same posted on discourse ]

I found a solution that works - using boot.kernelPackages = pkgs.linuxPackages_5_4; (for now), but using the unstable channel. This unfortunately does not work on the 19.09 channel. Corresponding discussion on discource

My case was simple. I own a Legacy NVIDIA card, and at some point, I suppose the default NVIDIA driver is no longer compatible with it. I'm not sure why the error doesn't appear in journalctl when using -u display-manager, but looking at all of journalctl showed me the driver was incompatible. The solution for me was to add this to configuration.nix:
  boot.kernelPackages = pkgs.linuxPackages.extend (self: super: {
    nvidia_x11 = super.nvidia_x11_legacy390;
  });

I'll keep this issue open because it seems @aniketd 's error is different from mine, and could be a bug in nixpkgs.

Thanks, can confirm linuxPackages_5_10 works. linuxPackages_5_4 has an unrelated bug with my system, so I'm glad there's a working kernel for me!

@matthewbauer @NixOSInfra Just bringing to your notice that may be this issue can be closed.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/fresh-system-after-graphical-install-hangs-on-started-display-manager/40970/6


returning error OCR Error:{"framesToPop":1,"code":"An error occured"}

Please help me out. I am gettting this error while in catch.

I am getting same error. when I run it on android device ,it is returning
** returning error OCR Error:{"framesToPop":1,"code":"An error occured"} **
Please provide any updation on the issue.


[Fix #3979] Excluded non-ruby files from files explicitly passed in arguments

Exclude ruby files from files paths passed directly. Makes the behavior between rubocop and rubocop [FILES...] consistent. (e.g. doesn't try to find offenses in .md files).
The source issue is #3979.

[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Used the same coding conventions as the rest of the project.
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[ ] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] All tests are passing.
[x] The new code doesn't generate RuboCop offenses.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[ ] Updated cop documentation with rake generate_cops_documentation (required only when you've added a new cop or changed the configuration/documentation of an existing cop).

Apart from the failing build the changes look good to me. This needs a changelog entry.

@bbatsov What do you think about using linguist to detect ruby files? They have a very accurate dataset of filenames, file extensions, and interpreters
Ruby:
  type: programming
  ace_mode: ruby
  codemirror_mode: ruby
  codemirror_mime_type: text/x-ruby
  color: "#701516"
  aliases:
  - jruby
  - macruby
  - rake
  - rb
  - rbx
  extensions:
  - ".rb"
  - ".builder"
  - ".fcgi"
  - ".gemspec"
  - ".god"
  - ".irbrc"
  - ".jbuilder"
  - ".mspec"
  - ".pluginspec"
  - ".podspec"
  - ".rabl"
  - ".rake"
  - ".rbuild"
  - ".rbw"
  - ".rbx"
  - ".ru"
  - ".ruby"
  - ".spec"
  - ".thor"
  - ".watchr"
  interpreters:
  - ruby
  - macruby
  - rake
  - jruby
  - rbx
  filenames:
  - ".pryrc"
  - Appraisals
  - Berksfile
  - Brewfile
  - Buildfile
  - Dangerfile
  - Deliverfile
  - Fastfile
  - Gemfile
  - Gemfile.lock
  - Guardfile
  - Jarfile
  - Mavenfile
  - Podfile
  - Puppetfile
  - Snapfile
  - Thorfile
  - Vagrantfile
  - buildfile

https://github.com/github/linguist/blob/master/lib/linguist/languages.yml

This should detect Gemfile and config.ru as Ruby files too. (I'm sure there are more.)

@mikegee I'm undecided between using Linguist and rolling my own classifier based on their data :) (loading linguist is pretty slow ~2.1s on my Macbook Pro)
This could actually end up being a much bigger change, e.g. would run cops on all Ruby-like files.
Interestingly enough, .rabl and .ruby files are currently ignored, but it sounds like they shouldn't

I'm not sure what to do about hidden files, seems like they should always be ignored, but apparently .pryrc is a thing and could be included I guess?

Also, by default .rake files are ignored (and that's quite a few files).
@bbatsov: Is it on purpose to ignore non .rb files? This will cause many more offenses on people's codebase (for good reasons) (e.g. > 100 in my case).

@bbatsov: Is it on purpose to ignore non .rb files? This will cause many more offenses on people's codebase (for good reasons) (e.g. > 100 in my case).

The purpose is to ignore non-ruby source files when you've used globbing in the command-like invocation. Why we didn't handle more Ruby source files formats? Probably an oversight...

They can add it to the exclusion list, isn't it enough?
On Sun, 5 Feb 2017 at 21:02, Bozhidar Batsov<EMAIL_ADDRESS>wrote:

@bbatsov commented on this pull request.
In lib/rubocop/target_finder.rb
https://github.com/bbatsov/rubocop/pull/3997#pullrequestreview-20196265:

@@ -3,6 +3,53 @@
require 'set'

module RuboCop

RUBY_EXTENSIONS = %w(.rb

I wonder if all these should be hardcoded instead of moved to the
configuration. That would make it possible for users to disable RuboCop for
certain types of files easily.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bbatsov/rubocop/pull/3997#pullrequestreview-20196265,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH4favL3upXGQLC7S-cDaARGfXgAYdvks5rZqlrgaJpZM4LzPjV
.

Yeah, you're right.

I've added a few small remarks about the tests. You should also update the changelog.

@bbatsov Should be good now, pretty excited about this one :)


High Precision TAI Timestamp

Hello,
Does this repository support TAI timestamps with greater precision than milliseconds? Like microseconds or even nanoseconds?

Right now this library only accepts integer millisecond counts as input and throws an exception otherwise. It also returns results truncated to the millisecond. The reason for this is that this is how JavaScript time is expressed.
However, there is some semi-secret internal infrastructure which carries out all the relevant calculations using precise ratios of BigInts. We only truncate at the very end, everything internal is exact. It could be possible to expose this for interface, or some kind of microsecond converter or nanosecond converter or similar.
What are your actual requirements? Or are you just curious?

MPEG is adding a TAI nanosecond timestamp capability for their HEIF & MP4 files. I'm wondering if there's any open-source tool to convert such a timestamp to/from a human readable form. However, It seems like everyone uses UTC with millisecond precision.
I would be interested in such an interface that handles an arbitrary level of precision.

I see. Well, some of the pieces for that are in place, but I wouldn't exactly call them suitable for public consumption, there's a decent amount of jank. Let me think about the best way to provide that interface.

@dukesook I should probably mention that you may be able to get away with:
const OFFSET_MILLIS = 37_000
const unixToAtomic = x => x + OFFSET_MILLIS
const atomicToUnix = x => x - OFFSET_MILLIS

Similarly for microseconds, nanoseconds or whatever. This implementation is sufficient for your needs provided that

you don't need to handle any dates prior to 2017, and
the abolition of leap seconds, currently expected to occur in or before 2035, is completed before any more leap seconds are announced, which on current showing seems quite possible.


typo: powerbi-docs/service-analytics-pane.md

transparecy -> transparency
dyanmic -> dynamic

@nschonni : Thanks for your contribution! The author, @mihart, has been notified to review your proposed change.

Verified the changes.

@ktoliver : Thanks for your contribution! The author, @mihart, has been notified to review your proposed change.


Camera preview is zoomed

Hello,
I used your library for generating preview and everything works fine except the face that video is zoomed compared to the preview from native camera. Any idea?

I have same issue for all camera libraries which I have found


RFP - B1 Free Archiver

B1 Free Archiver is a cross-platform file archiver and file manager.
https://www.b1.org/windows/
https://b1.org/download-windows

Status: Review
https://chocolatey.org/packages/b1freearchiver

Status: Rejected*
* due to high AV detection count.

https://chocolatey.org/packages/b1freearchiver

Can be closed.


initialization hanging with rtl8192eu

Hi. I bought another adapter with chipset rtl8192eu. I installed mange's driver and am able to use airodump. It works ok to capture packages. But it hangs when I use hcxdumptools.
# lsusb
Bus 001 Device 002: ID 2357:0108 TP-Link TL-WN822N Version 4 RTL8192EU
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

# ip link set wlan0 down
# iw dev wlan0 set type monitor
# ip link set wlan0 up
# iw dev
phy#0
	Interface wlan0
		ifindex 3
		wdev 0x1
		addr 50:3e:aa:48:0b:48
		type monitor
		txpower 12.00 dBm

airodump-ng is a passive dumper (it receive packets), while hcxdumptool is active (send packets; packet injection). That means, you can't compare airdodump-ng (passive) with hcxdumptool (active).
The driver must(!) support packet injection, but it looks like it doesn't. And following the link you posted, I can't find any useful information that this driver supports full packet injection.
Also wikidevi doesn't have information about this driver:
https://wikidevi.com/wiki/Rtl8xxxu
Supported modes
STA (Station) mode: supported
IBSS (Ad-Hoc) mode: unknown
AP (Master) mode: unknown
Mesh (802.11s) mode: unknown
P2P mode: unknown
Monitor mode: unknown
Packet injection: unknown
BTW:
Only TP-Link TL-WN822N v1/v2 support monitor mode and(!) packet injection.
There are tons of issues about v3 and higher like this here:
https://github.com/Mange/rtl8192eu-linux-driver/issues/88
and more here:
https://github.com/schollz/find-lf/issues/16
http://keep-it-sim.blogspot.com/2013/08/compatible-wireless-network-adapters.html
https://www.raymond.cc/blog/best-compatible-usb-wireless-adapter-for-backtrack-5-and-aircrack-ng/
There are also tx power issues running this driver:
https://github.com/Mange/rtl8192eu-linux-driver/issues/80
Closed, because it is a driver issue and not related to hcxdumptool.


[feat-5277]: Delete Scopes support for all plugins

Does this close any open issues?
Closes #5277
Screenshots
Include any relevant screenshots here.
Other Information
Any other information that is important to this PR.

The linter complains about deprecation issues that are outside the scope of this PR. I will not be resolving those.


PutObject with expires invalid

I putobject to minio with expires,but file did not delete after expires.
client version:github.com/minio/minio-go/v7 v7.0.70,
minio version:RELEASE.2024-05-10T01-41-38Z
my code:
uploadInfo, err := minioClient.PutObject(ctx, bucketName, objectName, file, fileSize,
minio.PutObjectOptions{Expires: time.Now().AddDate(0, 0, 1), ContentType: contentType})
which means this file will expire one day later.
is there something wrong with my code?

Expires is a cache header. It does not set when the object should expire - that functionality does not exist in S3.


Feature Request: Provide a configuration option to utilize Row Level Security features of SQL Server 2016 for multi-tenant scenarios

Using a new feature of SQL Server 2016, it now possible to provide excellent Row Level Security capabilities that allow leveraging SESSION_CONTEXT in conjunction with some related built in stored-procedures functions (i.e. two types of predicates--filter and block) to elegantly handle providing multi-tenant capabilities transparently to applications.  With SESSION_CONTEXT, you can inject user profile information (such as tenantId, userId, etc) in the ambient session which can be used by filter & block predicates to implement row level security, hence enabling 3-tiers architecture to leverage that feature.
It can be manipulated with the system stored procedure sp_set_session_context and can later be access with the SESSION_CONTEXT object:
EXEC sp_set_session_context 'user_department_id', 42;
SELECT SESSION_CONTEXT(N'user_department_id');
Adding this feature would be fairly benign, but would need to be configured by adding a call within IdentityServer4 internal wiring (for SQL served client/claims support) to create a SessionContextInterceptor within the SessionContextConfiguration (inherited from DbConfiguration) class.
For a better explanation of all this, please checkout the following link: Tutorial: Web app with a multi-tenant database using Entity Framework and Row-Level Security.
I really hope you consider adding this since Identity Server wouldn't required extension alterations in order to accommodate multi-tenancy using RLS features of SQL Server 2016.

What's an example of what you're ultimately trying to achieve with this?

Setting the message.tenantid from the acr into the Session_context to pass into SQL Server 2016. Also it might be very handy to also include Always Encrypted functionality of 2016 to encrypt claim values :)

Mark

On Sep 4, 2016, at 1:36 PM, Brock Allen<EMAIL_ADDRESS>wrote:
What's an example of what you're ultimately trying to achieve with this?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

So then the net effect would be requests to the DB from certain tenants would be isolated in some way?

That is correct

Mark

On Sep 4, 2016, at 6:08 PM, Brock Allen<EMAIL_ADDRESS>wrote:
So then the net effect would be requests to the DB from certain tenants would be isolated in some way?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I'm not a DB/SQLServer expert, but how does that provide additional security if the one connection string (the one being used from IdentityServer) has the power to switch to any tenant it wants?
Or is this less of a security feature, and more of an implicit filtering mechanism? I guess it must be more of the latter given that the context of your above issue is multi-tenancy.
I'm just trying to get my head wrapped around what this is really doing.

I think that the leveraging of some new 2016 features could help on both the filtering of content (ie multitenantcy) and on data at rest (security via Always Encrypted).  My primary interest though here is on multitenantcy and the desired to have built-in hooks to wire-up Session-Context data that can be accessed and automatically filtered via SQL Server 2016.  In essence this would required a hooking mechanism into the instantiation of the dbContext to make a call into a pluggable SessionContextInterceptor for the identity related tables and utilize a tenantId field on each of those tables.  Please check out this link for some examples.
-Mark

Given that this is a SQL Server specific feature, and all we're willing to support is EF, I'm inclined to close this issue. If you want to take the EF code and extend it so support this or build your own implementation, then we're happy to link to your repo. Thanks.


Add 33 byte checksum to seed.

This is only being done for compatibility with older dcrwallet
versions that refuse to decode word list seeds that are not 33 words
long when entering them from the console (the gRPC API accepts seeds
as simply a byte array so long as they are within the correct length
range).
Fixes #108.

reads right

tACK, seed is valid for dcrwallet now. Can be merged.


Set default type for generated Builder generic

Hi!
Thank you for the great work on the TypedBuilder, it is really nice to use.
I have quite big structs and therefore made a wrapper that boxes the contents, so that it can be passed around without causing stack overflows. I.e.:
#[derive(TypedBuilder)]
struct Inner {
    a: i32,
    b: i32,
}

struct Outer(Box<Inner>);

The issue now is, that I want to build the outer type like this:
let value = Outer::builder().a(3).b(5).build();

There is no way for a custom build function and that can be worked around by adding a function Inner::outer(self) -> Outer, so that would be acceptable, as it would result in:
let value = Outer::builder().a(3).b(5).build().outer();

However, it is not feasible to create the Outer::builder() function, as the generic type needs to be set to a tuple of empty tuples, given the number of fields. The number of fields is sadly unknown, so I cannot generate the builder function appropriately.
So I was wondering if it was possible to somehow provide the default type of the builder via a default type parameter (not sure if that works) or a trait (that should be easy, but a bit clunky). TypedBuilder would generate this:

default type parameter:

struct BlaBuilder<TypedBuilderFields = ((), (), ...)> { ... }

trait:

pub trait BuilderDefaultType {
    type DefaultType;
}

impl<R> BuilderDefaultType for BlaBuilder<R> {
    type DefaultType = ((), (), ...);
}

Then I could use it like this hopefully?:
impl Outer {
    // 1
    pub fn builder() -> InnerBuilder {
        Inner::builder()
    }

    // 2
    pub fn builder() -> <InnerBuilder as BuilderDefaultType>::DefaultType {
        Inner::builder()
    }
}

What do you think about this, is this something that is possible and would be accepted? Especially variant 1 should not really change anything besides adding the default type parameter and should be easy to add without any harm, right?

I guess the .outer() function can be replaced by the solution of https://github.com/idanarye/rust-typed-builder/issues/52 ?


[master] Upgrade to latest dependencies

Cron. -knative-prow-robot
/cc knative-sandbox/channel-wg-leads
/assign knative-sandbox/channel-wg-leads
Produced via:
./hack/update-deps.sh --upgrade --release v0.21
./hack/update-codegen.sh

Details:
bumping knative.dev/pkg ca02ef7...6045ed4:
  > 6045ed4 Allow setting DisableCompression in NewAutoTransport (# 2007)
bumping knative.dev/hack 8d623a0...8368e1f:
  > 8368e1f guard against set -o unset (# 49)
  > 2b4f6fc disable go's proxy and sumdb only for knative deps (# 47)
bumping knative.dev/eventing d58bd38...8171448:
  > 8171448 Adding Logline for when a cloudevent has been successfully sent from APIServerSource to the sink (# 4723)
  > fd2688d Use SHOULD for TriggerSpec to keep compatibility (# 4838)
  > 1fa597e [# 4796] Bump golang lint timeout to 10m (# 4830)
  > a4a9f48 Format markdown (# 4829)
bumping knative.dev/reconciler-test 2fa47da...0603b74:
  > 0603b74 Update common github actions (# 80)

/lgtm
/approve


Support '/dev/stdout' as a valid '--out' parameter

Proposed fix for issue #4841.
I have updated writeFile function for Node system. Essentially, I've ended with the code that @mklement0 suggested in his comment. The documentation states that:

process.stderr and process.stdout are unlike other streams in Node.js in that they cannot be closed (end() will throw), they never emit the finish event and that writes are always blocking [added emphasis].

The new behavior can be tested this way:
node built/local/tsc.js --out /dev/stdout hello.ts
node built/local/tsc.js --out - hello.ts

Can you comment on a proper way of testing this feature?
Thanks!

I don't know how WScript system works and if the issue is present there too or not.

@mhegazy @mklement0 I tried to analyze why node returns ESPIPE, invalid seek so I cloned node repo from Github, compiled it and run:
$ echo "require('fs').writeFileSync('/dev/stdout', 'hello');" | ./node

fs.js:707
    return binding.writeBuffer(fd, buffer, offset, length, position);
                   ^

Error: ESPIPE: invalid seek, write
    at Error (native)
    at Object.fs.writeSync (fs.js:707:20)
    at Object.fs.writeFileSync (fs.js:1235:24)
    at [stdin]:1:15
    at Object.exports.runInThisContext (vm.js:54:17)
    at Object.<anonymous> ([stdin]-wrapper:6:22)
    at Module._compile (module.js:425:26)
    at node.js:589:27
    at doNTCallback0 (node.js:430:9)
    at process._tickCallback (node.js:359:13)

So we have the line with binding.writeBuffer where parameter values are 11 <Buffer 68 65 6c 6c 6f> 0 5 0 (I simply used console.log() to output parameter values).
binding.writeBuffer call leads to calling SYNC_CALL(write, nullptr, fd, &uvbuf, 1, pos) and this command throws an exception (a debug statement of mine after this call is not printed). SYNC_CALL(write, ...) leads to calling uv_fs_write function and it finishes, I don't know where exactly is the exception thrown (it's not in SYNC_DEST_CALL).
To make a conclusion, the problem seems to be in the fact that fs.writeFileSync uses a buffer implementation which sets offset value 0 for writing to a file (it is stdout in our case). However, this is inconclusive because I don't know Node architecture and my knowledge of C++ is fairly basic.

Why can't you just make a call to openSync and use the returned file descriptor? That should do it.

@DanielRosenwasser You are right. This seems to work:
var fd = _fs.openSync(fileName, 'w');
_fs.writeSync(fd, data, undefined, "utf8");  // I can't use `0` as the third parameter (position) but I still need to set encoding parameter. I don't like it very much though.
_fs.closeSync(fd);

The behavior with the latest commit is:
node built/local/tsc.js --out /dev/stdout hello.ts # works
node built/local/tsc.js --out - hello.ts # creates '-' file :-)

@MartyIX :) So just adding if (fileName === "-") { fileName = "/dev/stdout" } would do the trick?
@DanielRosenwasser: By saying that it's not necessarily cross-platform, are you just referring to the - convention of representing stdin/stdout? If so: true, that's a Unix convention, but it would be convenient on Windows, too - the only caveat is that creating files literally named - would then require ./- as  a workaround, but I don't think that's much of a real-world concern.

@mklement0 I think so, yes.
I think that Daniel simply does not want to handle special cases because it's typically hard to do all the conventions right for all platforms. If one can come up with a solution without special handling, it also means that it will be easier to maintain it in future. My point here is not that "it's too much work, we won't do it".

@MartyIX: Understood.
Come to think of it, it is the /dev/stdout that's not portable - Windows has no analog, as far as I know (there is CON, which works in certain cases, but tsc simply creates a file by that name, which, due to using a reserved name, is then quite hard to get rid of, incidentally).
So the use of - could become the portable solution by fiat - it will then be the platform-neutral representation of stdout - but that also means that just mapping - to  /dev/stdout behind the scenes will not work on Windows.
That brings us back to process.stdout, which is Node.js' portable way for writing stdout, it seems to me - though there may well be issues I'm unaware of.
As it stands (just to summarize), your proposed PR would only benefit Unix users that use literal target /dev/stdout.

@MartyIX: Understood.
Come to think of it, it is the /dev/stdout that's not portable - Windows has no analog, as far as I know (there is CON, which works in certain cases, but tsc simply creates a file by that name, which, due to using a reserved name, is then quite hard to get rid of, incidentally).
So the use of - could become the portable solution by fiat - it will then be the platform-neutral representation of stdout when using tsc - but that also means that just mapping - to  /dev/stdout behind the scenes will not work on Windows.
That brings us back to process.stdout, which is Node.js' portable method for writing to stdout, it seems to me - though there may well be issues I'm unaware of.
Using - to mean "stdout, whatever it is on your platform" is a nice abstraction that requires minimal special handling - especially given that Node.js does the heavy lifting of handling stdout on all platforms.
As it stands (just to summarize), your proposed PR would only benefit Unix users that use literal target /dev/stdout, so it's inconvenient to use on Unix systems, and Windows users are left out altogether.

@mklement0 I agree with you. I like the former solution better than the current one too.
Yet, any accepted patch is better than none from my point of view because the current behavior of tsc is really awkward on my Linux box.

@MartyIX
Understood. Your patch is worth applying in any event, because it also fixes the inability to write to other kinds of special files, such as FIFOs (though that may be a more exotic use case).
And kudos for figuring out the issue with fs.writeFile[Sync] - you have to wonder whether the explicit 0 offset is intentional.
Ceterum censeo "-" esse implementam.

I was referring to /dev/stdout special handling. Glad to hear the fix worked @MartyIX. Dealing with general file descriptors is the right way to handle it, so I think this is the appropriate fix. I'll test it out in a bit.
I'm not totally against allowing - as an argument with special meaning, but that would address #1226 specifically. I'm also not concerned with WScript handling for this. I assume dealing with #1226 would be when we'd think about it.

@DanielRosenwasser: Glad to hear that - is not off the table; I just realized that I completely missed that this PR fixes  #4841, not #1226 (because a comment of mine from the latter was referenced) - dealing with those two issues separately makes perfect sense.

So this doesn't work when you request non-inline sourcemaps, but that's not a big deal.
Can you wrap the change in a try/finally? Open and write in the try, close in the finally.
Basically, initialize the file descriptor to undefined (but typed as a number) and if it's not defined in the finally block, don't close it.

@DanielRosenwasser Sure

Thanks @MartyIX!


Separate field for rotary engine indicator

separate field for rotary engine indicator to make it easier to use in rules, is it rotary or radial?

added field to indicate rotary engine


Create napari-menu conda-forge package

This will be just a wrapper package that provide menu entries for napari so they can be used by the new constructor installers.
Future work might also involve adding menuinst support for other platforms/desktops (e.g. Gnome and others on Linux).
xref https://github.com/conda-forge/napari-feedstock/issues/28

By menu, you mean OS menus, not menus in napari itself, right?

Correct!

Closed by https://github.com/conda-forge/napari-feedstock/pull/32