do not generate `.gitignore` and `.prettierignore` files (or offer option to disable generation)

[felix-roehrich]

Hey,

we tried out Paraglide and had an overall great experience, but we are currently put off by the fact that .gitignore and .prettierignore are generated on every compile. This clashes with our internal policy of committing generated source code to the repository. We do this for the following reasons:

• It makes code reviewing and browsing the repository easier with generated code present.
• It prevents "it works on my machine" issues and ensures a consistent env for all devs (and CI)
• It prevents unnoticed changes to generated code when updating (in this case) Paraglide

We believe it would be nicer for consumers if the setup only suggested to update the .gitignore and .prettierignore files (which probably already exist on a repository/package level) and left the final decision to the developer. Alternatively, an option to disable the generation would also be fine.

(As an aside, we were also surprised that .inlang is not a valid name for the project folder, since it common have config dirs be named .[tool].)

[samuelstroschein]

Hi Felix,

Well written issue, thank you. Do you still seek a disable option with the following context?

1. The inlang directory is actually a file-format. Hence, metadata is stored in the directory like the caching of modules/plugins.
   

2. If the .prettierignore and .gitignore handling is not automatically taken care of, every commit can lead to a merge conflict for metadata that should have been ignored.

3. If the consumer needs to manually update the prettierignore and gitignore files, chaos will likely erupt: Users don't know that they need to update the files or users ignore the prompt to update the files.

Given point 3, I suspect that the configuring manual updates of the gitignore file will not be used by users, and we should not offer it to avoid effort in customer support on our side.

PS Towards the end of the year you won't need to store an inlang directory in git anymore. More info coming soon.

[felix-roehrich]

Hi Samuel,

thank you for your quick response. Maybe my remark at the end is confusing you (sorry if that was the case). I was talking about the JS files generated by Paraglide (i.e. the ones in the paraglide folder), not the inlang folder. So there shouldn't be any metadata ? I agree that storing the cache from the inlang folder is not a good idea.

[samuelstroschein]

I was talking about the JS files generated by Paraglide (i.e. the ones in the paraglide folder), not the inlang folder.

Ah. I let @loris.sigrist take over.

Out of my head: the same problem of potential merge conflicts arises though, doesn't it?

• the compiled output should be gitignored. else, merge conflicts for every compile might emerge
• prettier ignore is likely not needed if the output is gitignored.

[felix-roehrich]

the compiled output should be gitignored. else, merge conflicts for every compile might emerge

The compiled output should stay the same, unless the source (the translation files) are changed. So there would only be a conflict if the translation files or Paraglide were updated. In the first case you would have a merge conflict either way.

Having the generated JS checked in guarantees that files shipped in production are exactly the same as in CI, testing, etc.

[samuelstroschein]

Having the generated JS checked in guarantees that files shipped in production are exactly the same as in CI, testing, etc.

Dont' you have that guarantee already by checking in the source translation files and pinning the paraglide version?

It seems like you would double-track changes to translations, which leads to two merge conflicts that should be one. The merge conflicts in the compiled messages can't even be resolved because they depend on the translation source files. If the translation source files and compiled message output are resolved differently, the compiled output does not equal the input. The result will be bugs or unexpected behaviour.

[LorisSigrist]

@felix-roehrich While I personally wouldn't check in generated files, I can see why you do & why that's your policy. I don't think you're making an unreasonable request here.

@samuelstroschein, what do you think of generating/modifying the .gitignore files once during paraglide-js init and then leaving it up to developers if they want to keep it? The behavior of generating ignore files already existed when I started working on paraglide, what was the original reasoning behind it?

[samuelstroschein]

@loris.sigrist i would add a config property to the compiler emitGitignore which defaults to true instead of implicit behavior.

The behavior of generating ignore files already existed when I started working on paraglide, what was the original reasoning behind it?

It avoids merge conflicts.

[felix-roehrich]

@samuelstroschein I believe you are overestimating the amount of merge conflicts happening. That said, this is based on our current experiences which does not include translations, so it may turn out that in this case this policy is unsustainable.

As for the double tracking let me make the following comparison (although it's not perfect): If you add a package with pnpm add you are kind of generating code. Now let me quote from pnpm

You should always commit the lockfile [...] it enforces consistent installations and resolution between development, testing, and production environments, meaning the packages used in testing and production will be exactly the same as when you developed your project

Sounds pretty similar to my arguments, right? So your argument in this case would be that it is sufficient to pin all the versions in package.json and a lockfile is superfluous. Verifying a hash in the lockfile is similar to testing if after generating source code the repo is still in a clean state. This is what we are doing. With pnpm-lock.yaml and package.json you can also get "two merge conflicts which should be one", but you are still using a lockfile.

Overall you don't need a lockfile and it usually doesn't make in difference, but you still use one. So why shouldn't one check in generated source code?

[samuelstroschein]

So your argument in this case would be that it is sufficient to pin all the versions in package.json and a lockfile is superfluous

Yes, if you pin your versions ;) Package managers don't pin exact versions by default, though. NPM uses SemVer aka ^1.0.0 will resolve different versions. That does not hold true for the translation files in your repo. Whatever translation file you checked out is the file you get.

PS let's add emitGitignore as config. Maybe even as experimentalEmitGitignore so that we can remove it again if users are reporting merge conflict problems/nobody uses the config prop?

[samuelstroschein]

@felix-roehrich is this still a feature you request? otherwise, I'll close the issue till more users request it

[felix-roehrich]

I don't need it urgently, since I can work around it. It's more of an annoyance, so feel free to prioritize other things.

[samuelstroschein]

Roger. I am going to expose the compiler as a library with v2. You will able to adapt the compiled output to your needs