aws-cdk: deprecation notices and module funding

❓ General Issue

deprecated deprecated deprecated

npm WARN deprecated @aws-cdk/yaml-cfn@1.98.0: This module is no longer supported and will be removed in a future release.
npm WARN deprecated request-promise-native@1.0.9: request-promise-native has been deprecated because it extends the now deprecated request package, see https://github.com/request/request/issues/3142
npm WARN deprecated urix@0.1.0: Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated har-validator@5.1.5: this library is no longer supported
npm WARN deprecated resolve-url@0.2.1: https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142

The Question

We aim to only use aws-cdk modules or nodejs native modules, however each time we do an npm install there is always some module that is either deprecated, or has a coder asking for funding.

Moving forward could you please include npm WARN deprecated in your tests and try not to release code that generates warnings.

Also, and this is a bigger issue, when you use external (non aws) modules, could you please make sure that you can provide payments to go from AWS to any 3rd party devs who are looking for funding for their repos. It is a bad look not only for AWS to exploit the good will of non AWS coders, but also especially given the disparity between AWS cashflow and many independent coders. Indeed when an Enterprise wants to use the aws cdk cli, and presents a demo to a production board for PoC/Review, npm i with warnings and funding requests doesn’t go down well.

Environment

• **CDK CLI Version:all
• **Module Version:all
• **Node.js Version:all
• **OS:all
• **Language (Version):ts

Other information

[smaud]

Closing a ticket before User Acceptance Testing is not desired behaviour.

In the meantime, simply not using the cdk init template or uninstalling jest after template creation are both options.

As it stands the main feature for recommending the enterprise use of CDK is the ability to test constructs and stacks. The work around, means that the production use case for CDK is removed, along with a compelling reason to recommend CDK.

To encourage the type of behavior we require, what we will do moving forward is attempt to include AWS CDK/Cfn team KPIs in our enterprise SLA to encourage the following outcomes:

• No closing GitHub tickets without customer UAT
• Zero deprecation notices from CDK install and CDK init features
• Zero 3rd party funding requests
• Zero npm audit/snyrk warnings
• CodeGuru code coverage and security reporting

Regards,

[njlynch]

Here are some sample dependency paths for each of the above:

urix:
jest@26.6.3 -> @jest/core@26.6.3 -> jest-haste-map@26.6.2 -> sane@4.1.0 -> micromatch@3.1.10 -> snapdragon@0.8.2 -> source-map-resolve@0.5.3 -> urix@0.1.0

resolve-url:
jest@26.6.3 -> @jest/core@26.6.3 -> jest-haste-map@26.6.2 -> sane@4.1.0 -> micromatch@3.1.10 -> snapdragon@0.8.2 -> source-map-resolve@0.5.3 -> resolve-url@0.2.1

request-promise-native:
jest@26.6.3 -> @jest/core@26.6.3 -> jest-config@26.6.3 -> jest-environment-jsdom@26.6.2 -> jsdom@16.4.0 -> request-promise-native@1.0.9

request:
jest@26.6.3 -> @jest/core@26.6.3 -> jest-config@26.6.3 -> jest-environment-jsdom@26.6.2 -> jsdom@16.4.0 -> request@2.88.2
nodeunit@0.11.3 -> tap@12.7.0 -> coveralls@3.1.0 -> request@2.88.2
lerna@4.0.0 -> @lerna/add@4.0.0 -> pacote@11.3.0 -> @npmcli/run-script@1.8.4 -> node-gyp@7.1.2 -> request@2.88.2
lerna@4.0.0 -> @lerna/bootstrap@4.0.0 -> @lerna/run-lifecycle@4.0.0 -> npm-lifecycle@3.1.5 -> node-gyp@5.1.1 -> request@2.88.2

har-validator:
request@2.88.2 -> har-validator@5.1.5

Both resolve-url and urix share a common path from jest to source-map-resolve.

As @kayuapi mentioned (thanks for the research!), the remainder are brought in by jsdom, as well as nodeunit and lerna (via node-gyp). The jsdom PR looks to be well on its way. I’d love to finish the work to get rid of our nodeunit dependency. lerna might be a longer wait; it looks like node-gyp@8 removes the dependency on request, but it’s nested pretty far down the dependency chain.

In short, I don’t think there’s an immediate “quick fix” to remove all deprecated dependencies, but we can take some steps to get incrementally closer, most immediate probably being removing our dependency on nodeunit throughout. However, this on its own won’t actually fix any of the above warnings.