Skip to content

Conversation

@jaerod95
Copy link
Contributor

@jaerod95 jaerod95 commented Apr 10, 2025

Overview

Restores support for parsing API tokens via a global config file.

Test Plan

Testing successfully completed in via:

  • Deleting your ~/.config/ditto file and then running the CLI should walk you through fetching and saving your api token.
  • Entering an invalid API Token should reprompt you to input a valid api token.
  • It should generate json files in your ./ditto/ directory in the repo when running pull, and pull down all projects with the base variant by default. This means a file for each project with the name of project-id___base.json
  • Setting some variants into your configuration should generate a different variant file per variant per project if variants exist for text items in that project for provided variants
  • Filtering by project ids should only fetch relevant text from projects.

jaerod95 added 11 commits April 7, 2025 11:10
… to the beta CLI

- adds a `--legacy (-l)` CLI option that forces the application to run in legacy mode.
- adds a new warning message when the CLI is run in legacy mode.
- Additionally removes the v8-compile-cache that provides little value in modern node applications of this size.
- Adds minification support via esbuild as well as cleaner map files.
- Updates package.json "files" property to now only ship required files to npm.
… on configuration. Update error handling in handleOutput to provide clearer output format messages. Add default value for generateDriverFile in ZI18NextOutput schema.
Copy link
Contributor

@marla-hoggard marla-hoggard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hitting submit on the first half of the code review so you can start working on the feedback. I've made it through the outputs directory. Still need to look through services and utils directories.

Copy link
Contributor

@marla-hoggard marla-hoggard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finished the code review! Comments are mostly small/nits, but the APIToken helpers need another pass, as the usage of the token parameter is inconsistent and not quite right (and currently includes type errors). I'll wait for you to update that set of methods before testing.

protected indentSpaces: number = 2;

protected sanitizeStringForJSVariableName(str: string) {
return str.replace(/[^a-zA-Z0-9]/g, "_");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, just interesting that we chose to make our default a character that we don't allow and ultimately replace here 🤷‍♀️

export async function initAPIToken(
token: string | undefined = appContext.apiToken,
configFile: string = appContext.configFile,
host: string = appContext.apiHost
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that this method is only called in one place, and in that place it's called without any parameters. Do we expect to update this implementation to call it elsewhere with parameters? If not, it might be best to just simplify and use the appContext values directly.

If we are going to keep the parameters, i would potentially change this to an object as well, since all three params are optional. I'd much rather see initAPIToken({ host: "ditto.com" }) than initAPIToken(undefined, undefined, "ditto.com").

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upon further inspection, i think you need to take another look at this method and the related token helpers. In my previous review, I noticed that checkToken was taking but totally ignoring a token parameter. You've since removed that unused parameter.

validateToken still takes a token parameter, but all it does is pass it into checkToken, which no longer accepts that, and then returns it. Meaning, that validateToken no longer needs to take a token parameter either.

Then the same is true in this method - it takes a token just to pass it into validateToken, which never uses that value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This format of params with defaults is meant to aide when it comes to being able to test this method easily. It's a stylistic choice that already existed in the legacy implementation, and since this was a copy then modify scenario from the legacy codebase, it's included. I personally like the concept for testing as long as it's a consistent theme throughout the the implementation. For now, not planning on updating it.

logger.errorText(
"Something went wrong. Please contact support or try again later."
) + eventStr
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do this same sentry code in several places. Might be nice to make a helper for it:

export const quitWithError = async (error: unknown, message?: string) => {
  const eventId = Sentry.captureException(error);
  const eventStr = `\n\nError ID: ${logger.info(eventId)}`;
  const errorMessage = message || "Something went wrong. Please try again later.";

  return await quit(logger.errorText(errorMessage) + eventStr);
};

Then lines 64-71 could simply be:

return await quitWithError(error);

Copy link
Contributor Author

@jaerod95 jaerod95 Apr 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds like a great follow up improvement!

…default interceptor for axios requests and update token validation logic to improve error handling and context management.
jaerod95 and others added 5 commits April 15, 2025 13:20
Co-authored-by: Marla Hoggard <[email protected]>
… github.com:dittowords/cli into jrod/dit-10045-reintroduce-pull-command-with-ns-cli
jaerod95 and others added 3 commits April 15, 2025 13:28
… and update fetchText function to stringify filters in API request parameters.
Copy link
Contributor

@marla-hoggard marla-hoggard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've done a bunch of testing and things are working well! I do have one piece of feedback, which we could fix here or as a followup. The UX for inputting an invalid api key is a bit strange. When I enter a bad value, my initial line updates to say "token (value)" and then the new prompt is already pre-populated with my bad value and then an error message two lines below where my cursor is. It's just a bit confusing/overwhelming.

This is the state of the terminal immediately after I hit submit on "bad.key" the first time
Screenshot 2025-04-15 at 5 14 43 PM

@jaerod95 jaerod95 merged commit b83b2c2 into v5-beta Apr 15, 2025
1 check passed
@jaerod95 jaerod95 deleted the jrod/dit-10045-reintroduce-pull-command-with-ns-cli branch April 22, 2025 16:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants