feat(chalk-to-util-styletext): add workflow

[richiemccoll]

Related issue

Fixes #198

Test cases

• basic
• advanced modifiers
• bg styles
• chained styles
• complex chaining
• commonjs require
• ESM dynamic import
• mixed imports and usage
• warn when un-migratable chalk api is found
• different importing methods
  • const mychalk = require('chalk');
  • const { red } = require('chalk'); maybe hard
  • const { red; foo }. = require("chalk");
  • const foo = await import('chalk');
  • const { red } = await import('chalk')
  • import * as chalk from 'chalk'
  • import { red } from 'chalk';
  • import { yellow as y } from 'chalk';
• dependency removal(?)

[AugustinMauroy]

don't miss to do a npm I at root of the repo to sync the lock file 😁
Also you can use multiple step codemod to separate job if needed like for https://github.com/nodejs/userland-migrations/tree/main/recipes/node-url-to-whatwg-url

For dependency removal I'm asking the Codemod team. because on V0 when the tools was JS only and there was a simple thing to manage dep

[AugustinMauroy]

some code style

[avivkeller]

@AugustinMauroy the PR is still a draft, no need to nitpick yet

[AugustinMauroy]

@AugustinMauroy the PR is still a draft, no need to nitpick yet

😅 oops I'm flash macqueen. Nop kidding just inattentive

[richiemccoll]

@AugustinMauroy I've pushed a few commits which I believe address some of the earlier comments. From the original Github issue, 7/8 test cases are passing. The one test case remaining is the complex chaining example.

const styles = level === "error" ? chalk.red.bold : chalk.yellow;

const styles =
	level === "error"
		? (text) => styleText(["red", "bold"], text)
		: (text) => styleText("yellow", text);

I have a rough idea/implementation locally for this, but it's a bit nasty and I'm not sure I like it.

But I'm keen to get feedback on this initial approach and understand if there are possibly better ways of implementing.

[AugustinMauroy]

I'm going to review your current code.

[AugustinMauroy]

WOW clean. About complex thing I didn't have any idea now I'm getting tired. But you do a great job here.

Missing tests/support about import.

• const mychalk = require('chalk');
• const { red }. = require(-'chalk'); maybe hard
• const { red; foo }. = require(-"chalk");
• const foo = await import('chalk');
• const { red } = await import('chalk')
• import * as chalk from 'chalk'
• import { red } from 'chalk';
• import { red as colorRed 'chalk';

For dependcy par you I'll need custom thing (new step on workflow.yaml):

• step that have JSSG child_process & fs capacity enabled
• function that use FS to detect which package manager it's use (npm, yarn, pnpm)
• new function on package-json utility that removes dep
  So jssg step will be architecture as:
• get the package manager
• remove dep with the utility function
• run the good child process

for this part I can take over the pr to help you.

https://docs.codemod.com/cli/packages/building-workflows#steps
https://docs.codemod.com/jssg/security

[AugustinMauroy]

LGTM for now the warning si good. Missing some piece that already in the todo.
If you doesn't want to do the dependency part I can do it in follow up pr.

[richiemccoll]

LGTM for now the warning si good. Missing some piece that already in the todo. If you doesn't want to do the dependency part I can do it in follow up pr.

Here's my plan for the remaining work:

• continue working my way through the remaining TODO's unless I run into any blockers.
• pull down some open source projects that use chalk and run the codemod to iron out any unforeseen issues
• take a look at the removal of the dependency

[AugustinMauroy]

Okay nice !

[AugustinMauroy]

the complex chaining handling is clever 👌🏻

[richiemccoll]

@AugustinMauroy I've pushed some commits that close off the remaining TODO's that were left from last week. I've also made an attempt at the dependency removal process that you mentioned above.

I've also done a bit of testing with this implementation across some open source projects that use chalk. It is largely working as expected, although I found some interesting use-cases which are not currently handled in this PR:

• Complex template literals

console.log(`You can now view ${chalk.bold(appName)} in the browser.`);
console.log(`Server running on ${chalk.cyan(`http://localhost:${port}`)}`);
console.log(`To build, run ${chalk.cyan(`${useYarn ? 'yarn' : 'npm run'} build`)}`);

• Nested chalk calls

console.log(chalk.underline(chalk.red("error")));
console.log(chalk.bold(chalk.yellow("warning")));
console.log(`Search for ${chalk.underline(chalk.red("keywords"))} to learn more`);

I'm happy to take a stab at those in this PR, although the amount of files now is starting to grow. It may make sense to do in a follow up. WDYT?

[AugustinMauroy]

could you add unit test for this file. using node:test & node:assert

[richiemccoll]

I've added an integration test here that tests this util. feat(chalk-to-util-styletext): add remove-dependencies integration test

[AugustinMauroy]

Suggested change

	visibility: public
	visibility: public
	capabilities:
	- fs
	- child_process

[AugustinMauroy]

https://docs.codemod.com/jssg/security#enabling-capabilities

[AugustinMauroy]

I'm happy to take a stab at those in this PR, although the amount of files now is starting to grow. It may make sense to do in a follow up. WDYT?

Why my comment above we are good to land and support rest after

[brunocroh]

Isn’t it better to list the covered scenarios instead of the uncovered ones? If new ones are added, will they be supported by default or not?

[richiemccoll]

Let's say for example, that Node.js adds hex support to styleText. With the denylist approach, we would have to remove it from UNSUPPORTED_METHODS and release a new version of the codemod.

On the other hands with the allowlist approach, we would have to add hex to the SUPPORTED_METHODS set (and release a new version).

My reasoning for going with the denylist is that it's a smaller surface area to maintain, 5 unsupported methods vs 20+ supported.

WDYT? either way, they require a similar maintenance burden. This is why I chose a more concise approach.