feat(crypto): add RSA-PSS codemod for DEP0154

[nievasdev]

Summary

Add codemod to transform deprecated RSA-PSS crypto options:

• hash → hashAlgorithm
• mgf1Hash → mgf1HashAlgorithm

Changes

• Only transforms crypto.generateKeyPair() and crypto.generateKeyPairSync() calls with 'rsa-pss' key type
• Supports both direct calls (crypto.generateKeyPair) and destructured imports (generateKeyPair)
• Comprehensive test coverage for various usage patterns

Test plan

• Tests pass for basic transformations
• Tests pass for destructured imports
• Tests verify non-rsa-pss calls are ignored
• Lint and type checks pass

Resolves #144

[AugustinMauroy]

good starting ! But there are missing piece:

• if user do import * as foo from 'node:crypto'
• if use do const { generateKeyPair: foo } = require('node:crypto')
  Solution: have this pr merged #151 EDIT it's merged you should use this utility

Also for strictness on parameters analyst you should do something like that:

for (const call of callNode) {
	const optionsMatch = call.getMatch("OPTIONS");
	if (!optionsMatch) continue;

	// Find the object node that contains the URL options
	const objectNode = optionsMatch.find({
		rule: {
			kind: "object"
		}
	});

	if (!objectNode) continue;

	// Find all property pairs in the object
	const pairs = objectNode.findAll({
		rule: {
			kind: "pair"
		}
	});

	// find hash pair then replace it
	pairs.find(pair => {
		const keyNode = pair.find({
				rule: {
					kind: "property_identifier"
				}
			});
		if (!keyNode) return false;

		const key = keyNode.text();
		if (key === "hash") {
			const valueNode = pair.find({
				rule: {
					kind: "string_fragment"
				}
			}) || pair.find({
				rule: {
					kind: "string"
				}
			});

			if (!valueNode) return false;

			const value = valueNode.text().slice(1, -1); // Remove quotes
			const replacement = `hashAlgorithm: '${value}'`;
			edits.push(call.replace(replacement));
			return true;
		}
		return false;
	});
}

[nievasdev]

Hi @AugustinMauroy, I updated the branch, I would appreciate any feedback, thank you for your attention.

[AugustinMauroy]

Nit

[AugustinMauroy]

this case should be handled

const algo =  'sha256';

crypto.generateKeyPairSync('rsa-pss', {
  modulusLength: 2048,
  mgf1Hash: algo
});

[nievasdev]

@AugustinMauroy @brunocroh thanks for you feedback, I did the changes witch you ask for,
Sorry for the delay, I had to be away for a while.

[brunocroh]

Nice work, thanks! 🚀

[nievasdev]

@brunocroh @AugustinMauroy. The code was getting big, so I refactored to a modular architecture.

[brunocroh]

@brunocroh @AugustinMauroy. The code was getting big, so I refactored to a modular architecture.

IMHO: The previous code probably had some areas that could be improved, but it was easier to follow.

TLDR: workflow.ts was split, but I don’t see much benefit. Splitting makes sense only when a file has multiple responsibilities or needs independent changes (like PR #172). Adding extra files here hides logic and makes it harder to follow. A consistent structure across codemods would help, but one-off architecture/splits just add complexity.

I can see that workflow.ts was split, but I don’t see any real advantage to this. Splits like this make sense when a file has issues with Separation of Concerns or when we’re trying to follow the Single Responsibility Principle.

In our workflow, we have a script that rewrites the file. I believe splitting the file only makes sense in cases where different parts need to change independently, like what PR #172 shows. In those scenarios, having a shared file for reusable parts can make sense.

In many other cases, adding extra files and utility functions doesn’t simplify the code. Instead, it hides what’s happening, making the logic harder to follow when it’s split across 3 or 4 files.

Maybe in the future, we can create a structure or architecture to apply consistently across all codemod recipes, making them easier to follow. However, the real advantage of such structures comes when they form a pattern used across the project. Having just one codemod recipe with a different and more complicated pattern will only make it harder to understand, as it will be completely different from the rest.

---

Again, just my opinion. Let’s see what the maintainers think.

[AugustinMauroy]

Again, just my opinion. Let’s see what the maintainers think.

Agreed with Bruno. But @nievasdev I understand that you spend a lot of time on your PR and that it takes a lot of energy. And I'm very happy to have people who are so invested in the project.

[nievasdev]

@brunocroh you got a point, I think you're right, I'll make the code structure like the previous ones,
@AugustinMauroy you spend a lot of time too,
I'm not going to abandon the project. I understand that these first issues are for learning, so don't worry about me getting discouraged, haha 😄
And thank you very much for taking the time to review my commits.

[AugustinMauroy]

for me it's an LGTM

[brunocroh]

LGTM 🚀🎉

[nievasdev]

@brunocroh @AugustinMauroy, how are you? Are there other things we should change? How should I continue with this work?

[brunocroh]

@brunocroh @AugustinMauroy, how are you? Are there other things we should change? How should I continue with this work?

We need one more member to review/approve before proceeding with the merge.
We are currently waiting for feedback from the team.

[nievasdev]

Good, could I take another issue while I wait, or is it better if I just wait?

[AugustinMauroy]

Good, could I take another issue while I wait, or is it better if I just wait?

yeah if you want you can open an second pr