#5 Workaround generating wrong provides for bundled modules
Closed by tomh. Opened by zvetlik.
zvetlik/nodejs-packaging master  into  master

Download 5.patch

While packaging yarn, the generated provides were:

bundled(nodejs-ajv) = 5.5.2
bundled(nodejs-ansi-escapes) = 3.0.0
...
bundled(nodejs-xtend) = 4.0.1
bundled(nodejs-yn) = 2.0.0
nodejs-yarn = 1.5.1-2.fc29
npm(ajv) = 5.5.2
npm(ansi-escapes) = 3.0.0
...
npm(yarn) = 1.5.1
npm(yn) = 2.0.0

This is wrong, because npm(module) dependencies shouldn't be generated.
This produces:

bundled(nodejs-ajv) = 5.5.2
bundled(nodejs-ansi-escapes) = 3.1.0
...
bundled(nodejs-xtend) = 4.0.1
bundled(nodejs-yarn) = 1.5.1
bundled(nodejs-yn) = 2.0.0
nodejs-yarn = 1.5.1-2.fc29

bundled(nodejs-yarn) = 1.5.1 is clearly wrong, but it is easier to fix than hundreds of wrong npm(module) provides.

Well that doesn't look right at all - that call to handle_module is for the top level module, which isn't bundled, which is why changing it is wrongly marking yarn as bundled.

When we recurse into genuinely bundled modules the flag is set as expected.

I know you had said the bundle detection wasn't working a while ago, but I did actually test it and it seems to work fine for me.

And does it produce right Provides for you?

Well it seemed to when I tested it manually but I tried a build with some bundled modules yesterday and saw the same problem as you so I'm going to investigate some more, but probably not until the weekend.

I think b7cbbe4f0 is the real fix and I have now build version 14 of nodejs-packaging for f28 and rawhide with that fix.

Pull-Request has been closed by tomh

handle_package_json(path, bundled=bundled) at the beginning of handle_module is called on every path that is passed to it with the set flag, so when it is set to False, it first generates npm(module) provides for everything and after that it checks if there are any bundled modules too and generates bundled(nodejs-module) provides

Metadata