Sherlock on `@inlang/sdk2`
Starting work on integrating @inlang/sdk2 into Sherlock.
TODO:
- [x] transform all vscode actions + tests to SDK v2
- [ ] transform all vscode commands + tests to SDK v2
- [ ] copyError.test.ts
- [ ] copyError.ts
- [ ] createMessage.test.ts
- [ ] createMessage.ts
- [ ] editMessage.test.ts
- [ ] editMessage.ts
- [ ] extractMessage.test.ts
- [ ] extractMessage.ts
- [ ] jumpToPosition.test.ts
- [ ] jumpToPosition.ts
- [ ] machineTranslate.test.ts
- [ ] machineTranslate.ts
- [ ] openInFink.test.ts
- [ ] openInFink.ts
- [ ] openProject.test.ts
- [ ] openProject.ts
- [ ] openSettingsFile.test.ts
- [ ] openSettingsFile.ts
- [ ] openSettingsView.ts
- [ ] previewLocaleCommand.test.ts
- [ ] previewLocaleCommand.ts
- [ ] toggleInlineAnnotation.test.ts
- [ ] toggleInlineAnnotation.ts
- [ ] transform all vscode decorations + tests to SDK v2
- [ ] transform all vscode diagnostics + tests to SDK v2
- [ ] transform all services + tests to SDK v2
- [ ] transform all utility functions + tests to SDK v2
🦋 Changeset detected
Latest commit: 1e42cbf65fc84d9c793af76e6e321dfd0a2a5dd5
The changes in this PR will be included in the next version bump.
This PR includes changesets to release 15 packages
| Name | Type |
|---|---|
| @inlang/paraglide-next | Minor |
| @inlang/paraglide-js | Patch |
| @inlang/paraglide-unplugin | Patch |
| @inlang/editor | Patch |
| @inlang/paraglide-next-e2e | Patch |
| @inlang/paraglide-next-example-app | Patch |
| @inlang/paraglide-next-example-pages | Patch |
| @inlang/paraglide-next-example-turbo | Patch |
| @inlang/paraglide-sveltekit | Patch |
| @inlang/paraglide-js-e2e | Patch |
| @inlang/paraglide-sveltekit-example | Patch |
| @inlang/paraglide-rollup | Patch |
| @inlang/paraglide-vite | Patch |
| @inlang/paraglide-webpack | Patch |
| @inlang/paraglide-astro | Patch |
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
@samuelstroschein
Following questions:
-
Is
NodeishFileSystemlegacy and now onlytypeof import("node:fs/promises")is used? -
Does that mean everything has to be rewritten / remapped (all Sherlock functions, all cross-selling packages etc.)?
-
I need
listProject, can I put it in SDK v2 or should I move it to Sherlock? -
Can you translate this query into sqlite format so I can see how it works?
const _message =
state().project.query.messages.get({
where: { id: message.messageId },
}) ?? state().project.query.messages.getByDefaultAlias(message.messageId)
- What is the solution for
project.customApi()["app.inlang.ideExtension"]?
customApi() doesn't seem to exist anymore, only in a project.plugins.get() which points to the InlangPlugin interface (unresolved).
-
When do I have to use the
project.dbvs theproject.lixAPI? -
When does the work on validation rules start & where does it get tracked? Sherlock can't be release on sdk v2 without those as they mark a major functionality/feature.
-
What happens to
_importon theloadProjectinterface (which is likely needed by Sherlock for importing modules)?
Is NodeishFileSystem legacy and now only typeof import("node:fs/promises") is used?
Yes. You can use the node fs directly.
Does that mean everything has to be rewritten / remapped (all Sherlock functions, all cross-selling packages etc.)?
Jein. NodishFs was a subset of node:fs/promises. Which means that you shouldn't have a problem. Problematic could be the overloads. Created an issue to remove the overloads https://github.com/opral/inlang-sdk/issues/136
I need listProject, can I put it in SDK v2 or should I move it to Sherlock?
You need to do it in Sherlock with a globbing function. See https://www.npmjs.com/package/fast-glob#onlydirectories as an example.
const projects = fg.sync('*.inlang', { onlyDirectories: true });
For context, lix/fs had no globbing support, leading to listProjects. listProjects emulated a glob. cc @LorisSigrist this applies to you as well.
Can you translate this query into sqlite format so I can see how it works?
Yes, reference the docs of kyseley https://kysely.dev/docs/examples/select/a-single-column.
Here is the translated query (hope it works). Keep in mind that alias.default has been removed. What you want to query is "give me a message where the id is this or one of the aliases is the id (not only querying the default alias)
const bundles = await project.db
.selectFrom('bundle')
.selectAll()
// eb = expression builder
.where((eb) => eb.or([
// either the ids is equal to the message id
eb("id", "=", message.messageId)
// or the default alias (alias is a json that's why the --> syntax) is equal to the messageId
eb(eb.ref("alias", "-->").key("default"), "=", message.messageId)
]))
.execute()
Or with the selectBundleNested helper query:
const bundles = await selectBundleNested(project.db)
// eb = expression builder
.where((eb) => eb.or([
// either the ids is equal to the message id
eb("id", "=", message.id)
// or the default alias (alias is a json that's why the --> syntax) is equal to the messageId
eb(eb.ref("alias", "-->").key("default"), "=", message.id)
]))
.execute()
What is the solution for project.customApi()["app.inlang.ideExtension"] ?
-
addCustomApi()will be deprecated due to https://github.com/opral/inlang-sdk/issues/125 - Only sherlock uses the custom API feature, hence here is a proposed workaround:
const plugin = project.plugins.get().find((p) => p.addCustomApi)
const customApi = plugin.addCustomApi()
customApi['app.inlang.ide-extension']
When do I have to use the project.db vs the project.lix API?
Everything change control related (history, commit, etc.) is queried via project.lix. The latest state of an inlang project (bundles, messages , variants) is queried via project.db. In the future, we might be able to offer one API under project.db which can join over the lix database.
When does the work on validation rules start & where does it get tracked? Sherlock can't be release on sdk v2 without those as they mark a major functionality/feature.
Here is the lix validation rule project https://linear.app/opral/project/lix-validation-rules-bdf46c532aa1/overview.
We agreed on releasing the inlang SDK2 without validating rules. And validation rules are likely 2 months away. The value of inlang SDK 2 with variants is higher than the interim loss of validation rules.
I propose building Sherlock SDK2 and, once it's ready, asking users if they prefer a Sherlock release with variant support but no interim validation rule support.
What happens to _import on the loadProject interface (which is likely needed by Sherlock for importing modules)?
Ups, I forgot to expose preprocessPlugin. I will add the function
await loadProjectFromDirectoryInMemory({
preprocessPlugin: yourPreprocessFunction(),
})
@felixhaeberle i merged https://github.com/opral/monorepo/pull/3070. you can now use preprocessPluginsBeforeImport in loadProjectFromDirectory