tsLoaderDefinitionFileVersions is changing between builds

[artola]

Expected Behaviour

tsLoaderDefinitionFileVersions should be deterministic and output always the same source.

Actual Behaviour

tsLoaderDefinitionFileVersions is changing between builds (without any source code change), producing that webpack's hashing to get invalidated.

Steps to Reproduce the Problem

Please see discussion on webpack issue and findings: webpack/webpack#8419 (comment)

Location of a Minimal Repository that Demonstrates the Issue.

https://github.com/artola/webpack-bug

Running a few times the same build it will produce different file hashes due changes in tsLoaderDefinitionFileVersions.
The repo contains a demo with 2 files (foo.ts and bar.ts) and what I can see is that they are "sometimes" processed in different order ("foo then bar" most of times, until happens "bar then foo") producing the mentioned problem.

[johnnyreilly]

Thanks for taking the time to raise this. I've read and re-read this but I'm afraid I'm not sure what the issue you're encountering is or what tsLoaderDefinitionFileVersions is? Could you clarify please?

Also, if you'd like to work on this then please do have a go; I can try and advise as you do perhaps.

[artola]

Thanks for taking the time to raise this. I've read and re-read this but I'm afraid I'm not sure what the issue you're encountering is or what tsLoaderDefinitionFileVersions is? Could you clarify please?

Also, if you'd like to work on this then please do have a go; I can try and advise as you do perhaps.

@johnnyreilly Thanks. I would like also to understand better why this happens, and help to fix it if possible, I would really appreciate some hint, what could be the culprit? any guess?

As I understand tsLoaderDefinitionFileVersions is metadata and somehow it is changing between builds, what leads to having a different hash for the file. (when in webpack we have an output like filename: '[name].[contenthash].js', ... I believed that this contenthash was calculated from the sourcecode content, but it also is related to the metadata used in the bundling).

ts-loader/src/index.ts

Line 488 in e9ef049

loaderContext._module.buildMeta.tsLoaderDefinitionFileVersions = allDefinitionFiles

It can be reproduced as this:

• clone the repo

• run yarn

• manually change the file node_modules/webpack/lib/NormalModule.js by adding these 2 console.log

  		const handleParseResult = result => {
  			console.log(this.resource);
  			console.log(this.buildMeta);
  			this._lastSuccessfulBuildMeta = this.buildMeta;
  			this._initBuildHash(compilation);
  			return callback();
  		};

• run the command yarn build > log1 && yarn build > log2

• compare the result of log1 and log2 ... often they match, but sometimes they not.

When they do not match, the "hash" created is different, for example:

run1:
  Entrypoint trial = trial.main.f509bbd03caa2c35371b.js

run2:  
  Entrypoint trial = trial.main.91c7f7d86f11c81a2577.js

[johnnyreilly]

Gosh I haven't looked at that code for a long time and I can't remember too much about it!

I'd advise debugging and seeing how the values can change. Is it just ordering? Or is it a different number of entries as well?

Start answering those questions and maybe that will lead to some potential solutions

[artola]

@johnnyreilly I found that this is related somehow to the order of the entries, for example having webpack.config.js:

    ...
    // sometimes foo is compiled first, otherwise it is bar and the hash will change
    entry: {
      trial: [path.resolve('src/foo.ts'), path.resolve('src/bar.ts')],
    },

    // changing to use an index file that just re-export the all from the other 2, will not fail
    entry: {
      trial: [path.resolve('src/index.ts')],
    },

Also it works fine, if I "force" to have a fresh instance by commenting the if in getTypeScriptInstance.

ts-loader/src/instances.ts

Line 49 in 37a0731

if (instances.hasOwnProperty(loaderOptions.instance)) {

[johnnyreilly]

Interesting. Can the allDefinitionFiles sort order be enforced (order by name perhaps) to resolve the issue as well?

Or can the order of instances be enforced?

[artola]

Interesting. Can the allDefinitionFiles sort order be enforced (order by name perhaps) to resolve the issue as well?

I tried, it is a bit better but not a full solution, because there is different number of entries when the failure happens also. :(

[johnnyreilly]

How about instances order?

[artola]

How about instances order?

instances is just an object that keeps the compiler instances, by default 1 named 0_default.

ts-loader/src/instances.ts

Line 49 in 37a0731

if (instances.hasOwnProperty(loaderOptions.instance)) {

This instance is called and re-used to compile each file, somehow this is affecting the result when the files are compiled in different order (foo/bar or bar/foo).

The problem happens only when using onlyCompileBundledFiles: true (with false the tsLoaderDefinitionFileVersions always output the same content).

webpack.config.js

                {
                  loader: 'ts-loader',
                  options: {
                    onlyCompileBundledFiles: true,
                  },
                },

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale. Please reopen if you'd like to work on this further.