plugin API where is a message used in source code for "unused message", "hardcoded text", etc. lint rules

[samuelstroschein]

Problem

Several problems that relate to code can not be linted at the moment. For example:

1. Is this message used? unused messages lint rule #1961
2. Does code include hardcoded text that needs to be extracted?
3. lint rule: "a message should only be used once" #2253

Proposal

Introduce an API for plugins to report where a message is used in source code.

The information where a message is used in source code can be used for several features:

• decorators in @opral/inlang-ide-extension
• a lint rule that detects unused messages
• providing context in @opral/inlang-fink and other apps where a message is used

Thinks to consider

• performance/caching of parsing source code (querying @opral/lix for changes of a file seems to be a quick win and good requirement for lix repo.fs.file("some-file").lastChange())
• how can the API take as much work from plugin authors as possible e.g. in regards to caching & handling performance

mentioned on a call with @PeerRich. cc @opral/inlang-sdk

[felixhaeberle]

@opral/inlang-sdk I have thoughts on this.

Architectural background.

Plugins currently have a customApi where app specific behavior can be registered. This leads to plugins having a customApi registered for the VS Code extension / all other possible IDE's (in the future).

Challenge.

Now comes the interesting part, these customApi's are optional. If they are optional, the resulting codeLintRule would then be optionally defined too and would have a dependency on a defined customApi property, namely messageReferenceMatcher.

We have to think about this dependency and how we potentially going to integrate it into the @opral/inlang-sdk

[samuelstroschein]

we wouldn't use customApi for this feature

[felixhaeberle]

Great 👍 I would have proposed the same but haven't had the time to write up an alternative approach because we have to collect requirements first.

[janfjohannes]

@samuelstroschein not sure i understand where lix would come into place here would caching parse results not be application layer above lix?

[janfjohannes]

@samuelstroschein what woudl lastChange return?

[samuelstroschein]

@janfjohannes TBD. a date would already be helpful to build caching.

Using the new temporal API with timezones because a change can occur in multiple timezones

const cachedAt = cache("file.txt").zonedDateTime

const lastChange = await repo.fs.file("file.txt").lastChange()

if (lastChange.zonedDateTime.after(cachedAt){
  invalidateCacheFor("file.txt")
}

Does the example above illustrate the usefulness of a lastChange() API?

[janfjohannes]

you can get the timestamp of the last commit a file was modified like this. is this what you need? (the api is isogit of course and should be made prettier but not sure your api is the right approach either..)

(await repo.log({ filepath: 'file.txt' }))[0].commit.author.timestamp

[janfjohannes]

and there is of course the modified time of fs.stat ...

[samuelstroschein]

(await repo.log({ filepath: 'file.txt' }))[0].commit.author.timestamp

The last commit doesn't help. Someone would need the last change irrespective of whether committed or not. The fs.stat API of modified is also not useful. If a file has been modified, which could be triggered by cloning a repo, doesn't matter. What matters is if the content (semantically) changed.

Your remark yields that lastChange() should likely return the status of a file (making repo.log and stat partially redundant):

const lastChange = await repo.fs.file("file.txt").lastChange()

// informs whether staging,committed, etc.
lastChange.status 
lastChange.zonedDateTime

[samuelstroschein]

discussion moved to opral/inlang-sdk#8