Lock Dredd Transactions' dependencies instead of Dredd's

[honzajavorek]

🚀 Why this change?

It should make this problem smaller.

📝 Related issues and Pull Requests

• Remove C++ dependencies using distributed npm-shrinkwrap.json #1168
• Change how the package works 🚚 dredd-transactions#196

✅ What didn't I forget?

• To write docs
• To write tests
• To put Conventional Changelog prefixes in front of all my commits and run npm run lint

[honzajavorek]

So apparently, locally npm is still able to somehow magically evaluate that protagonist is a dependency of drafter and adds it to the lock file.

I'm giving up on this broken tool. I don't know about Yarn's lock file, but my impression from both package-lock.json and npm-shrinkwrap.json is that they do a lot of stuff, mostly random or magic, but they rarely lock anything the way I need it.

I don't think a lock file is really needed on Dredd, it is a nice to have. So will add a commit here removing it. Hopefully that will bring an end to all this hassle with protagonist for a while.

[honzajavorek]

The commit is there.

So the current state is - installing Dredd from npm shouldn't compile protagonist and the surface of the hardwired dependencies should be smaller as after this PR we're distributing only Dredd Transactions's dependencies locked, not all Dredd's dependencies. This is probably the best we can achieve.

For local installations (cloning Dredd's repo and executing npm install, adding a dependency to Dredd, etc.), npm generously ignores whatever is locked, and attempts the compilation every single time. I see no way how to prevent it. I don't know whether this happens for people having Dredd as their dev dependency as well. It is very annoying, but I'll hope that with the arrangements made, me and my imaginary team are the only ones left suffering the compilation on everyday basis.

Completely removing lock file from Dredd at least avoids the need for preventing npm to regularly put the protagonist back to Dredd's locked dependencies (again, I don't know how to avoid this), and avoids the need for custom correcting of that file (postshrinkwrap script, etc.).

[realityking]

Scoping this down to dredd-transactions, while not perfect, is definitely a nice improvement. Thank you!

Another approach you could investigate is adding fury-adapter-apib-parser. It should allow you to modify your node_modules before running npm pack, leaving you with the desired result.

Your earlier PR reminded me of this problem so I took a shot at what, IMHO, the proper solution would be: making protagonist truly optional. This would require a breaking change to fury-adapter-apib-parser, I made a PR with a proposal here: apiaryio/fury-adapter-apib-parser#37

[honzajavorek]

I'm also wondering whether a certain combination of bundling dependencies wouldn't get rid of the compilation altogether.

[ApiaryBot]

🎉 This PR is included in version 5.4.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[honzajavorek]

So if I install Dredd now, it takes much less time and generates a smaller lock file. However, if I install it as a dev dependency of something, the compilation appears with all subsequent npm manipulations:

$ npm init -y
$ npm i dredd --save-dev  # doesn't compile
$ npm i sinon --save-dev  # triggers compilation
$ npm i  # triggers compilation
$ cat package-lock.json | grep protagonist
            "protagonist": "^1.6.0"
    "protagonist": {
      "resolved": "https://registry.npmjs.org/protagonist/-/protagonist-1.6.8.tgz",

😞

This really isn't a robust solution to the problem. I hope it's gonna be temporary, I'm done with hacks for now, this should be solved on the level of the drafter packages.