Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add possibility to override default path to config file #667

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

whalemare
Copy link
Contributor

Related to #656

Allow pass additional parameter to cli named as --project, that allow users to override default '.typesafe-i18n.json' path to config file

Save backward compatibility to allow current users change nothing in it's workflow.

Tested locally with command

typesafe-i18n -p /Users/whalemare/dev/project/some/relative/path/to/config/.typesafe-i18n.json

Copy link
Owner

@ivanhofer ivanhofer left a comment

Choose a reason for hiding this comment

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

Thanks for the PR. I haven't tested it yet. I just took a look at the changed files and added a few comments. Please make sure that the exporter and importer functionality works too :)

@@ -81,7 +81,7 @@ export const setup = async (autoSetup: boolean) => {

const config = await getConfigDiff(options)

await writeConfigToFile(config)
await writeConfigToFile(config, '.typesafe-i18n.json')
Copy link
Owner

Choose a reason for hiding this comment

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

don't you need to use options.project here too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When I wrote this, I think that this setup method is used only for in-place config generation, not for generate config in path passed by --project path

We can add path here too if needed

Copy link
Owner

Choose a reason for hiding this comment

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

I think it would be more consistent if someone is able to pass the -p flag also to the setup function.

@@ -22,12 +25,12 @@ const run = async () => {

logger.info(`version ${version}`)

await checkAndUpdateSchemaVersion()
await checkAndUpdateSchemaVersion(options.project)
Copy link
Owner

Choose a reason for hiding this comment

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

can we add a validation here?
The string should end with .json and we should check if the file exists (except if it is a setup call).


export const readConfig = async (): Promise<GeneratorConfig> => {
const generatorConfig = await readRawConfig()
export const readConfig = async (configPath = '.typesafe-i18n.json'): Promise<GeneratorConfig> => {
Copy link
Owner

Choose a reason for hiding this comment

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

I would not use default values anywhere. This makes it easy to miss a spot where we forgot to pass it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Did you have some ideas, how we can save backward compatibility with previous codebase that have hardcoded path to file, without default values?

Copy link
Owner

Choose a reason for hiding this comment

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

Ideally it get's passed from the CLI and .typesafe-i18n.json is the default value there if -p does not get specified.
Without having a look at the code, I currently don't really know where this function get's called. But the call stack to this function should only be initiated from the CLI or the exporter & importer I think

packages/generator/src/generator.mts Show resolved Hide resolved
@ivanhofer
Copy link
Owner

@whalemare I saw this PR was not updated for a while. Do you plan to continue working on this PR?

@whalemare
Copy link
Contributor Author

whalemare commented Jun 2, 2023

@whalemare I saw this PR was not updated for a while. Do you plan to continue working on this PR?

Yes, but little bit early. We can close this PR if you want and I reopen it or create new one, when I will be ready

@ivanhofer
Copy link
Owner

No it's fine. We can keep it open if you plan to continue working on it.

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.

2 participants