> Possibly, I don't really know what exactly it does and how it works > internally.
It's horrible code and I'm not surprised that it's horribly broken. Incidentally, there's a PR where I tried to cleanup the code a tiny bit: https://github.com/apache/cordova-lib/pull/650. But I would be happy to ditch it altogether. I actually suggested replacing it with something like `npm outdated | grep cordova` in the major release planning doc. It actually does a bit more than that, but not particularly well. --- > Is `cordova platform update` still really a thing? Apparently so. In the face to face meeting, @purplecabbage talked about having done some work-in-progress to improve it. I guess it's important for workflows that do not treat the `platforms` directory as purely generated artifacts :man_shrugging: --- > Is [`cordova platform check`] maybe also broken anyway? I dare you, take a look at the code. It would surprise me if it wasn't broken :grin: --- > What `platform check` definitely does not do is cover the CLI itself and > plugins, which a filtered result set from `npm outdated` could do. I agree. I think it would be good to have that. We should keep it simple, though. No plugin version conflict resolution or trying to install platforms like `platform check` does. --- > Ugh, I just learned that not all projects have their platforms and plugins in > package.json which means that npm outdated may not know enough (yet?). Progressive enhancement? Could be an incentive to switch to more modern workflow. We should maybe also be clear about what kind of project setups and workflows we want to continue to support. [ Full content available at: https://github.com/apache/cordova-cli/issues/304 ] This message was relayed via gitbox.apache.org for [email protected]
