Open anatoly314 opened 4 years ago
ryan-roemer
commented
4 years ago Hi @anatoly314 !
Can you run through the steps outlined in https://github.com/FormidableLabs/inspectpack/issues/125#issuecomment-569348664 ? The separate duplicates and versions reports will give us more to work with.
Thanks!
anatoly314
commented
4 years ago What directory are you running inspectpack from? From root folder of my project
/Users/anatoly/Documents/git/kodi-remote-subtitlesWhere are you node_modules directories? (Are you running commands from project root with only node_modules existing? Are you running commands from ROOT/packages/MY_PKG where ROOT/packages/MY_PKG/node_modules and ROOT/node_modules might both have installed packages? ...?) I'm running project from root folder where
node_modulesplaced
You can see my project here: https://github.com/anatoly314/kodi-remote-subtitles
ryan-roemer
commented
4 years ago Thanks! @keithcom and I have been looking into this. I think there's two things going on:
main.sass with css-loader and mini-css-extract-plugin. This is already covered by https://github.com/FormidableLabs/inspectpack/issues/125readable-stream stuff, the current versions action works by introspecting package.jsons so that you get more than just a report on disk where stuff ended up in node_modules, but rather a logical dependency view of the transitive dependency path, completely irrespective of how npm/yarn flatten things on disk. It appears that readable-stream is added by webpack as part of Node library polyfilling, and thus doesn't have a tracedable package.json:dependencies path for the current logic of the versions action.@keithcom traced the dep path to:
readable-stream
<- hash-base
<- md5
<- create-hash
<- crypto-browserify
<- node-libs-browser
<- webpackAssuming that all checks out, we'll probably re-title this ticket to something like "Webpack added node internals aren't found in versions" or something. Stay tuned for more!
ryan-roemer
commented
4 years ago We now have a simplified error case of an application that entirely consists of:
const crypto = require("crypto");
console.log(crypto.createHash("sha256").update("hello", "utf8").digest());When we then run:
$ cd test/fixtures/node-libs
$ node ../../../bin/inspectpack.js -s dist-development-4/stats.json -a duplicates
$ node ../../../bin/inspectpack.js -s dist-development-4/stats.json -a versionsWe get an analogous situation for the readable-stream portion of things (many duplicates, but no versions found).
ryan-roemer
commented
4 years ago @anatoly314 While we work through this I think your practical takeaway is:
You have duplicates of readable-stream stuff and:
versions in this webpack-added scenario and thus the DuplicatesPlugin which relies on both versions and actions data is similarly not working correctly.yarn.lock or something heavy handed, I think you're probably stuck with it.You have falsely reported duplicates for your .sass stuff from a pre-existing bug that are not actual duplicates, but instead the same file included differently by two different plugins/loaders.
Trying to use this plugin together with VueJS project generated by vue-cli 3.0, but have the following issue:
Missing sources: Expected 126, found 0.and don't get a list of duplicated resources. When I open mydistfolder, I see thatsource mapgenerated if it what it means.What I do wrong?
My
vue.config.jsis following:And full output by
inspectpackif following