Regression: wrong module versions get packaged when wrongly deduped

[trieloff]

On the dev site, @filmaj experienced a regression of #645 (ajv 5x ends up in html.zip instead of ajv 6x).

I haven't been able to reproduce it using the helix-cli integration tests yet, so we need to check against the actual dev site setup.

@filmaj can you describe your development setup?

• hlx version
• installed where
• installed how

[filmaj]

hlx version: 0.13.11-pre.8
installed via package.json: {dependencies:{"@adobe/helix-cli":"0.13.11-pre.8"}}
installed via npm install

[filmaj]

Then from https://github.com/adobe/developer.adobe.com e.g. cd branch, run hlx clean && hlx build && hlx package, then unzip .hlx/build/html.zip and run grep version .hlx/build/node_modules/ajv/package.json. Expectation: 6.0.0 or newer. Actual: 5.5.2.

[tripodsan]

the problem is that the current module-pack algorithm, include the module that is most top level module if there are duplicates.
when installing helix-cli globally (or via installer), it also respects the devDependencies which include ajv@6. but when installing locally, it doesn't and the ajv in ./node_modules/@adobe/helix-cli/node_modules/ajv is the one from request, since it doesn't need the devDependencies one.

the quick workaround is to add ajv@6 as normal dependency to helix-cli, in order to pull it up into it node_modules.

the correct fix is probably, to detect the duplication, and try to keep the ajv@5.x local to request.

[tripodsan]

temporary workaound applied in @adobe/helix-cli@0.13.11-pre.8-test