Optionally read config from package.json

[jbergstroem]

Many packages (eslint, prettier, list goes on) optionally supports storing/reading their config as part of package.json. It would be great if typescript-i18n would follow suit.

[ivanhofer]

HI @jbergstroem,
thanks for your suggestion. I will keep that in mind but it has a low priority right now.
Feel free to open a PR if you would like to see this feature happen sooner :)

[ivanhofer]

This could be an easy solution to add support for multiple config definitions: https://github.com/antfu/unconfig

[jbergstroem]

I came across lilconfig the other day at work, seems to have similar goals (smaller footprint than cosmicconfig).

[jbergstroem]

I can probs take a look at this soon. Would it only affect where to look for a config or also where to write the config, etc?

[ivanhofer]

I find merging configs not so good. This could lead to confusion where a specific option comes from.

I just realized, we don't relly need a library for reading package.json.
We could just read the json file directly and access the typesafe-i18n attribute (similar like here: packages/cli/src/setup/package-json.ts).
We could check if a .typesafe-i18n.json file exists (see doesConfigFileExist() in packages/config/src/config.ts) and if not, we try to load the config from the package.json.

What do you think?

[jbergstroem]

I find merging configs not so good. This could lead to confusion where a specific option comes from.

Most config libraries exposes this as an option.

I just realized, we don't relly need a library for reading package.json. We could just read the json file directly and access the typesafe-i18n attribute (similar like here: packages/cli/src/setup/package-json.ts).

Sure!

We could check if a .typesafe-i18n.json file exists (see doesConfigFileExist() in packages/config/src/config.ts) and if not, we try to load the config from the package.json.

I'll give it a go as soon as I have a moment.

[ivanhofer]

Most config libraries exposes this as an option.

@jbergstroem do you know the reasons behind this? From my current point of view I don't see why this should be an option :)

[jbergstroem]

@jbergstroem do you know the reasons behind this? From my current point of view I don't see why this should be an option :)

It's a pretty common pattern applied in 12FA; having a set of defaults that gets overridden by passing another context such as environment variables or additional config files (dotenv comes to mind). Having the passed context 'null' the existing state is most often not what you want; only to modify it.

[ivanhofer]

@jbergstroem thanks I now u derstand what you mean.
Just for package.json and the .typesafe-18n.json file, this makes not much sense since both files will probably get committed to SCM.
Overriding these configs via . env or by passing options to the cli would make more sense.
The cli currently not supports otions, but it would be great if we can add it. Let me know if you need some help.

[vhscom]

Many packages (eslint, prettier, list goes on) optionally supports storing/reading their config as part of package.json. It would be great if typescript-i18n would follow suit.

I'd like to point out the argument OP makes is presented argumentum ad populum when what I believe they were trying to argue for was consistency in their project set-up.

A reason not to use package.json is that many NPM build pipelines retrigger dependency downloads when the manifest is modified. When config changes it should not cause dependencies to download in a build pipeline. And while PNpM supports installation of deps from a lockfile only it's not a common pattern yet as far as I'm aware. I do like the Antfu project @ivanhofer pointed to earlier. That seems more appropriate solution to manage configs.

Reflecting on the why behind this issue I think it's because modern projects are getting a bit busy with config files these days. A solve for that is to create a config directory and move config in there and urge projects to provide sensible defaults such that no config is needed at all under the default behavior.

[jbergstroem]

I'd like to point out the argument OP makes is presented argumentum ad populum when what I believe they were trying to argue for was consistency in their project set-up.

I respectfully disagree with your opinion about my opinon. I have adopted a pattern many other libraries provide and suggested it as an optional. I don't see how this is so different from being able to provide a custom path to a file in a .config directory.

When config changes it should not cause dependencies to download in a build pipeline.

Couldn't agree more. In open source github actions I maintain I always provide examples with passing path (as part of when a job should trigger) to manage CI minutes spent. That's a configurable though, a pattern I am suggesting to use here as well.

TBF I said I'd PR and haven't gotten around to it yet, sorry about that.

[ivanhofer]

@vhscom I can see why you don't want to see configuration inside package.json and I personally don't like it either.
And I also can see that having dozens of tools in your repo each with its own config file is also something that annoys some people. To also providing the option to have the config inside package.json would satisfy both sides.

In my opinion configuration for typesafe-i18n should be like this:

• .typesafe-i18n.json file as default
• package.json with typesafe-i18n as a property
• no merging of configs! If .typesafe-i18n.json is present, package.json get's ignored
• maybe also a .js file with a default export?
• add a config-file option to the CLI where a custom path to the .json-config file can be specified
  e.g. typesafe-i18n --config-file .config/typesafe-i18n.json
• add each option that the config provides as a flag to the CLI. This makes it possible to override something on demand

Any comments on this idea?

Since I don't have the ressources available right now, I'm happy to see someone helping me out.
@jbergstroem mentioned he want's to create a PR. Since the scope increased a bit from "just providing package.json support", I'm not anymore sure if you still want to offer your help ^^