run hooks as a CI process instead of using the browser to do it

[ivanhofer]

Once the editor saves a Resource, it could potentially not match the style guide of that project. @samuelstroschein and I have spoken about adding a afterResourceWrite hook to the inlang.config.js file that would get executed in the browser after a Resource was written to disk.

Problem:
eslint, tsc, prettier and other tools need to download a few MB of code and have problems running in the browser or don't run at all.

Solution:
Run them in a CI process after the editor makes a commit (using Github Plugin, Action or similar tools for other hosting provider).
If no CI is set up a husky git hook could be added or a simple cli command can be used.

[samuelstroschein]

Here is a maintainer expressing the desire to run prettier MagicMirrorOrg/MagicMirror#3025 (comment).

[samuelstroschein]

Solution:
Run them in a CI process after the editor makes a commit (using Github Plugin, Action or similar tools for other hosting provider).
If no CI is set up a husky git hook could be added or a simple cli command can be used.

My gut tells me that adding a afterResourceWrite hook is out of scope for inlang / should be implemented by devs in their CI/CD pipelines or by a plugin in writeResources itself. Regarding ci/cd pipelines, that's one of the major benefits of inlang: use your ci/cd for automation.

But, how could we foster the development of GitHub actions and CI/CD "apps" that leverage @inlang/core?

[ivanhofer]

My gut tells me that adding a afterResourceWrite hook is out of scope for inlang

Agree, but we probably need a way to detect when changes were made by the editor to trigger a custom workflow.

Another use case is: running the type generator of typesafe-i18n :)

But, how could we foster the development of GitHub actions and CI/CD "apps" that leverage @inlang/core?

I think at the beginning it would be great to have some examples in the docs or in an example repo to showcase that it is possible to write custom behavior.