Align with webpack api.

[eladchen]

This change will remove the annoying deprecation message below, and will be backwards compatible.

P.S I noticed the tests are failing so I couldn't rely on them.

DeprecationWarning: Chunk.modules is deprecated. Use Chunk.getNumberOfModules/mapModules/forEachModule/containsModule instead

[faceyspacey]

fantastic!!! Perfect timing. Bout to release something big, and the warning is just cheap. I'll be merging it soon.

[faceyspacey]

Excellent job!

[faceyspacey]

I'll publish it soon. In the future use the npm run cm command as noted in the readme so changelogs, releases etc are created and so travis auto-publishes it to npm.

[eladchen]

@faceyspacey Will do.

[faceyspacey]

the isChunk function is giving people problems. Do you know why that might be?

#53
#54

[eladchen]

@faceyspacey I'm not sure, if I'll have to guess, it's probably a webpack change of somesort.

Are there any reproducible examples?

[birdofpreyru]

Hey ppl,
I run into chunk is not an instance of Chunk issue yesterday. Puzzled me a bit. I found out that issue happens when extract-css-chunks-webpack-plugin ends up installed into node_modules directory of a dependency, and is required from that dependency, e.g.:

- package_1
  - node_modules
    - package_2
      - node_modules
        - extract-css-chunks-webpack-plugin
      - webpack_config_piece

Say, webpack_config_piece requires extract-css-chunks-webpack-plugin and is used as a part of Webpack configuration for the build of the root package_1. In this case extract-css-chunks-webpack-plugin is loaded from package_2's node_modules, and it seems it fails to resolve some paths, but fails to report it clearly. If I bend my setup a bit to ensure that extract-css-chunks-webpack-plugin is installed only into package_1's node_modules everything works smoothly.

I suspect that it happens because under the hood extract-css-chunks-wepback-plugin resolves some paths relative to its location (__dirname) and not to the actual context of the on-going Webpack build.

[eladchen]

@faceyspacey Do you have any pointers to guide me where to look for @birdofpreyru's claims?

[birdofpreyru]

@eladchen @faceyspacey
Hold on guys, it seems it may be not a fault of your plugin that some dependencies are not resolved correctly in my case. Though, please merge my PR #57: it enhances the error reporting by the isChunk(..) function to show the actual cause why a chunk was not correctly created, rather than a dummy message everybody sees now.

[birdofpreyru]

Actually, hold on with this as well, my PR does not properly catch errors in building of sub-modules, I gonna update it later today.

[birdofpreyru]

@eladchen @faceyspacey I believe, this is it: #58

P.S.: Nope, appears it still does not capture all possible errors that may take place during Webpack build :( I guess, I'll surrender here, and will just use --bail flag on my build process to debug the problems.

[faceyspacey]

@eladchen honestly, I know very little, except lots of people have been having this problem as of late in the 2 linked issues. I pointed them to this PR to discuss--let's just wait until someone actually having the problem has a repro and/or more info.

@birdofpreyru thanks for working on this. it sounds like ur going down the right path. Extra reporting can't hurt. I'll merge your PR if and when you think it should be merged.

[birdofpreyru]

@faceyspacey yeah, I am pretty sure that the problem is that something outside you plugin crushes during the build, so Webpack does not produce proper Chunk objects; and the only reason why people complain about your plugin is that it checks that those chunks are not real Chunks, and throws an obscure error right away, before Webpack has a chance to correctly report the problem.

And my PR, although it somewhat improves the reporting, it does not catch all possible errors: while playing with this yesterday I managed to come into situation when chunks do not contain error messages where I look for them, but they are still not valid chunks, thus the obscure message is thrown again. I don't know the details, but I believe, Webpack should have some custom system for error messaging: if user did not opted out for --bail it just collects all errors that happened during the build and reports them in the very end of the process. So, the correct fix would be to update your plugin to collaborate with that system: if a chunk is not a Chunk, it should just properly record the error into Webpack API, and then exit without an error, returning control to the Webpack, rather than terminating the entire process.

[faceyspacey]

1. What's the api to report the error to webpack?

2. Are you saying that this check doesn't matter? I had a feeling that was the case. In what cases does it matter?

[birdofpreyru]

1. I am not familiar with Webpack internals; I am just saying that other plugins, when they encounter errors, they don't interrupt the build process, they just somehow message their errors to Webpack, so that it continues the build, and prints all the errors in the final log output, along with the result Build successed or Build failure. I have no idea, how they do it, and whether there is some "Error API" for that, or just some code pattern for that, but it seems they don't throw for that.

2. The check is still necessary, because if the chunk is not a Chunk, then your plugin will call some methods absent on chunk, and it will crush the code. But inside the check you should not throw, you should just message Webpack about the error, and then just ignore that chunk.

[manjula-dube]

Hey

b1d48e1

doesn't still fix the problem and I still get the same error of chunk is not instance of Chunk

[birdofpreyru]

@manjula91 yeap, it does not fix it, it just tries to better report the actual cause of the crush.

@faceyspacey I found another problem with that isChunk(..) check in its current form. Say, I have my webpack config split across two packages, say APP and LIB. All calls to extract-css-chunks-webpack-plugin are in the piece of config placed into LIB, and the conifg from APP just imports the LIB's config, probably tunes just a few settings, and then uses the resulting config for Webpack build.

When I install 'LIBintoAPP` normally, my dependecy tree is:

--- APP --- node_modules --- extract-css-chunks-webpack-plugin
                          |
                          |- LIB
                          |
                          |- webpack

and the compilation works smoothly.

Now, I want to npm link LIB into APP for development purposes. Because of the way npm link work, I end up with the following structure of directories:

--- APP --- node_modules --- symlink to LIB
                          |
                          -- webpack (1)


--- LIB --- node_modules --- extract-css-chunks-wepback-plugin
                          |
                          |- webpack (2)

and in this case, the compilation fails because of the incorrect isChunk(..) check. What happens, in my current understanding, the chunks passed into your plugin are instances of Chunk object from webpack (1), but inside your plugin the Chunk object is loaded from webpack (2), thus chunk instanceof Chunk returns false because these are two different Chunk prototypes.

In this very case, if I just remove the check, the compilation goes smoothly till the end. Not sure, what is the best way to fix it properly. Probably, instead of chunk instanceof Chunk it is better to check that the given chunk provides expected object interface?

[thisizkp]

what @birdofpreyru mentioned is true, instead of instanceof it is better to check for the expected object interface; that would fix the problem with npm link