samuelstroschein/inlang-plugin-json

InlangSdkConfigError: `sdk` property missing

Closed this issue · 18 comments

WarningImHack3r commented

While trying to setup inlang in my SvelteKit project, I encounter this error:

InlangSdkConfigError: The `sdk` property is missing in your `inlang.config.js` file.`. Make sure to use the `sdkPlugin` in your `inlang.config.js` file.

Steps that led to this error

  • Using @inlang/cli to configure inlang ➜ manually created the file because of this open issue
  • Create the inlang.config.js pasting the example in the Getting Started page
  • Head over to SDK for SvelteKit, add the @inlang/sdk-js dependency and import the plugin into my vite.config.ts
  • Run pnpm dev and get an error telling that inlang can't find the specified languages folder (which I didn't create yet)
  • Create the language folder in ./src/locales/{language}.json and replace the path in the config file
  • Run pnpm dev again and get this SDK error
samuelstroschein commented

Can you provide the inlang.config.js file that you used?

WarningImHack3r commented

Literally the one from your example page with a different path:

export async function defineConfig(env) {
	const { default: pluginJson } = await env.$import(
		"https://cdn.jsdelivr.net/gh/samuelstroschein/inlang-plugin-json@2/dist/index.js"
	);

	return {
		referenceLanguage: "en",
		plugins: [
			pluginJson({
				pathPattern: "./src/locales/{language}.json"
			})
		]
	};
}
samuelstroschein commented

I see our docs are misleading. The correct config for the sveltekit SDK can be found here.

You are not using the sdkPlugin for SvelteKit. Here is a working config:

export async function defineConfig(env) {
	const { default: pluginJson } = await env.$import(
		"https://cdn.jsdelivr.net/gh/samuelstroschein/inlang-plugin-json@2/dist/index.js"
	);

	const { default: sdkPlugin } = await env.$import(
		"https://cdn.jsdelivr.net/npm/@inlang/sdk-js@0.1.1/dist/plugin/index.js",
	)

	return {
		referenceLanguage: "en",
		plugins: [
			pluginJson({
				pathPattern: "./src/locales/{language}.json"
			}),
                        sdkPlugin({
				languageNegotiation: {
					strategies: [
						{ type: "localStorage" }
					],
				},
			}),
		]
	};
}

@NiklasBuchfink seems like we should not only split the landing page by app but also the docs.

  • 👍1
WarningImHack3r commented

Ok, it fixed the issue, however now the vite plugin inlangPlugin() leads to a lot of errors and fails my project to build, related to stuff it's trying to add in the wrong places in my code.
I may also suggest updating the URL of the sdk-js import to 0.2.0 (which didn't solve the issue with your inlangPlugin()), which is the latest version which is installed from npm. Couldn't we just import the dependency directly? Why install it and import it in 2 different ways?

samuelstroschein commented

Couldn't we just import the dependency directly? Why install it and import it in 2 different ways?

Everything in the inlang.config.js, including (inlang) pugins, runs in the browser too. A dependency on NPM becomes a nightmare in the browser. We have a lengthy discussion about the problem over at opral/monorepo#669 (comment).

The two version/import is problematic though. I proposed a solution in 669 that uses a "shell" package that auto downloads the correct version.

inlangPlugin() leads to a lot of errors and fails my project to build, related to stuff it's trying to add in the wrong places in my code.

What errors are you getting? Are they similar to opral/monorepo#679?

WarningImHack3r commented

Hmm, I see yeah... I guess that's one of the reasons why inlang.config.ts is not a thing?
How do the other Svelte(Kit) i18n packages - sveltekit-i18n, typesafe-i18n - handle the situation?
Inlang looks really promising but I feel like the way it's built is a bit "hacky" and in an early stage though.

Anyway, my problem is not #679, it's a problem with this line:

{#if $language}

trying to put itself on top of my +layout.svelte. The problem is that I'm using a:

<svelte:window bind:... />

binding on top of my +layout.svelte and this leads to an error stating that this binding cannot be wrapped into a statement (which makes sense).

ivanhofer commented 
InlangSdkConfigError: The `sdk` property is missing in your `inlang.config.js` file.`. Make sure to use the `sdkPlugin` in your `inlang.config.js` file.`

I wrote the error message befor the docs were a thing ^^. I forgot to add the link. I will do that now

@WarningImHack3r please open an issue here if you have a problem with the SDK.

samuelstroschein commented

Hmm, I see yeah... I guess that's one of the reasons why inlang.config.ts is not a thing?

Correct. Using .ts would require a transpilation step in the browser. Ivan just opened an issue on how to achieve typesafety without .ts files opral/monorepo#689.

How do the other Svelte(Kit) i18n packages - sveltekit-i18n, typesafe-i18n - handle the situation?

We have to separate packages. One for inlang (plugin) and one for vite (sveltekit). The inlang plugin has strict browser compatible requirements. The vite plugin can work like any svelte plugin. We are separating both "plugins" to make this separating clear and decrease the potential for bugs, see opral/monorepo#690.

Inlang looks really promising but I feel like the way it's built is a bit "hacky" and in an early stage though.

The SvelteKit SDK is early. The web editor is mature and can be used with any i18n library as long as a plugin exists (or you write your own). What makes inlang look promising to you?

WarningImHack3r commented

Thanks for those details! I'm not really into inlang's internals so I don't really get the reasons of all your problems but I can understand it's tough to deal with all that.

What makes it promising:

  • its really nice web UI (not the core of the thing but it counts a lot)
  • (future) ci integration
  • web editor & auto git integration
  • (future) support for more frameworks

So yeah that's a lot of things I've never seen elsewhere (at least for Svelte) and your team seem ambitious from what I can see

  • ❤️3
samuelstroschein commented

I just forwarded your message to Nils and Niklas who are designing and engineering the editor. They will surely be delighted to hear that you appreciate the UI!

And, you totally got the value prop of inlang! Localization deeply integrated into git and software engineering workflows like CI/CD.

I'll close this issue because the issue is unrelated to the plugin-json. But, feel free to keep the conversation about inlang going or join our discord https://discord.gg/gdMPPWy57R

  • ❤️1
WarningImHack3r commented

As I've seen, Inlang is the replacement for typesafe-i18n isn't it? How old is the project?

From an external POV, here are some points I may suggest to you:

  • Improve the docs. The onboarding process is not clear and straightforward enough, I had to randomly browse the other doc pages to figure out what to do after getting my inlang.config.js up.
    Also maybe move the https://github.com/inlang/ecosystem repo to a simple doc page of the website, exiting the docs and being redirected to an external link which is a GitHub repo with a single README file doesn't seem to be a good choice IMO.
    Finally, I could see here and there some mismatching examples between the environment repo and the Getting Started page, gathering all that can be once again a solution to avoid multiple sources of info, and a good tip would be to try integrating some code check in your CI pipeline. That's what Rich did for the Svelte docs and I think it's a fantastic idea to make sure the doc is always up to date and tested on the current codebase to avoid misinformation and too much open issues because of typos.
    To sum up: some cleanup, page refactoring/reordering & potentially CI/CD from https://github.com/inlang/inlang
  • Clearly mark unimplemented features as unimplemented. From the landing page it seems that everything is up and ready, and that's also what I could understand from your Svelte Summit presentation last Saturday (where I heard of you the first time), but it's not the case. Put some Upcoming badges on the docs pages that are, and clearly make it clear from the landing page that those features are not here yet.
  • Ease/explain the installation steps. Maybe explain why some steps are mandatory, used for, and look duplicate (typically for the duplicate between manual import in the config file and installation of the npm package). As for my personal experience, I found your doc really complex. I just wanted to get 2 things from a SvelteKit i18n: easy installation and setup & optional manual overriding of the browser language. Inlang offers this and everything I already mentioned, but I found myself getting information all over the place, SDK config, different parsing plugins, 2-3 doc steps for installation... To sum up: not easy to follow and overly complicated when you know what you're looking for but you can't easily find it.
  • Move all inlang-related repos to the inlang org. Pretty straightforward and avoids confusion and separated code.
  • Rename your npm package. Not a big thing but I don't get why your named it @inlang/sdk-js: if it's on npm, it can't be something else than JS!

Sorry I was already writing when you closed the issue haha, I'll probably join your Discord and maybe even contribute if I manage to find some time but for now it's complicated!

samuelstroschein commented

As I've seen, Inlang is the replacement for typesafe-i18n isn't it?

No, inlang itself is not a typesafe-i18n replacement. But, the sdk-js is a typesafe-i18n replacement.

Inlang is an ecosystem of applications and plugins to streamline localization/i18n. The main apps consist of a web editor, ide extension, CLI (for CI/CD), and now an SDK. All apps can be used independently of each other, or in combination.

How old is the project?

Nearing the two-year mark with a full year of only R&D and prototyping. The first prototype was shared on Svelte's Reddit https://www.reddit.com/r/sveltejs/comments/p4h6bg/proof_of_concept_internationalize_a_svelte_app_in/.

The onboarding process is not clear and straightforward enough, I had to randomly browse the other doc pages to figure out what to do after getting my inlang.config.js up.

One struggle we are having is that inlang is multiple apps that have a common denominator, namely the inlang.config.js file but the configs (slightly) differ per app. A pull request is ongoing, see opral/monorepo#676.

Your feedback there on getting started is highly appreciated!

Also maybe move the https://github.com/inlang/ecosystem repo to a simple doc page of the website, exiting the docs and being redirected to an external link which is a GitHub repo with a single README file doesn't seem to be a good choice IMO.

The idea was a CI/CD pipeline to test the ecosystem similar to the way Vite handles their ecosystem and make it easier for external developers to open pull requests. But, this is not established yet and the UX of reading about the ecosystem on the docs is better in any way. Thus, yes, we should move the ecosystem to the docs. I opened an issue opral/monorepo#698.

integrating some code check in your CI pipeline. That's what Rich did for the Svelte docs and I think it's a fantastic idea to make sure the doc is always up to date and tested on the current codebase to avoid misinformation and too much open issues because of typos.

Can you point me to the way Svelte does code checks for docs?

Move all inlang-related repos to the inlang org. Pretty straightforward and avoids confusion and separated code.

Planning on doing that. The plugin-json was not supposed to become a major plugin :D I will move it to the inlang repo if JSDelivr doesn't get hiccups.

Rename your npm package. Not a big thing but I don't get why your named it @inlang/sdk-js: if it's on npm, it can't be something else than JS!

Because a sdk-flutter, sdk-ios, etc. will follow. We need to separate the directories of those sdk's in the source code and referring to the sdk-js in the docs instead of SDK should clear things up.

opral/monorepo#700

WarningImHack3r commented

No, inlang itself is not a typesafe-i18n replacement. But, the sdk-js is a typesafe-i18n replacement.

Yes okay makes sense (pretty much what I had on my mind but I said it wrong)

One struggle we are having is that inlang is multiple apps that have a common denominator, namely the inlang.config.js file but the configs (slightly) differ per app.

Yeah, I feel you. However, you could simply link all possible ways to continue setting up your environment depending on your framework from the bottom of Getting Started. This way the user is guided and nothing is duplicated.

Your feedback there on getting started is highly appreciated!

No problem! I enjoy helping you get better.

The idea was a CI/CD pipeline to test the ecosystem similar to the way Vite handles their ecosystem and make it easier for external developers to open pull requests.

AFAIK your website is the documentation folder of https://github.com/inlang/inlang isn't it? Then why is CI/CD a problem?

Can you point me to the way Svelte does code checks for docs?

I heard this from a conference he gave at Vercel not so long ago, I could try digging through https://github.com/sveltejs/svelte to find out exactly how he did that.

Because a sdk-flutter, sdk-ios, etc. will follow. We need to separate the directories of those sdk's in the source code and referring to the sdk-js in the docs instead of SDK should clear things up.

I agree, however, GitHub repo name and NPM package name are two different things; can't you name your package NPM @inlang/sdk and keep the repo named sdk-js? If you can't, my bad, I wasn't aware of this.

samuelstroschein commented

I agree, however, GitHub repo name and NPM package name are two different things; can't you name your package NPM @inlang/sdk and keep the repo named sdk-js? If you can't, my bad, I wasn't aware of this.

Renaming packages on NPM is not possible. Besides, I would find that confusing. sdk-js is explicitly referring to the js SDK, @inlang/sdk could refer to any SDK if read out of context [of npm packages].

Yeah, I feel you. However, you could simply link all possible ways to continue setting up your environment depending on your framework from the bottom of Getting Started. This way the user is guided and nothing is duplicated.

Good point. @NiklasBuchfink plans a new landing page and eventually docs (?) that targets frameworks more specifically.

The idea was a CI/CD pipeline to test the ecosystem similar to the way Vite handles their ecosystem and make it easier for external developers to open pull requests.

AFAIK your website is the documentation folder of https://github.com/inlang/inlang isn't it? Then why is CI/CD a problem?

Yeah, premature optimization. I mentioned in opral/monorepo#698 that moving ecosystem into the main repo seems to make sense.

  • 🚀1
WarningImHack3r commented

Last suggestion before closing this for good:
Integrate every possible example (Svelte & SvelteKit with every different config basically) in your CI/CD to check if they build successfully with your latest code. I've opened 3 issues so far with a (quite simple) SvelteKit project and I still can't make it work 😅

samuelstroschein commented

Forwarded your idea to the test issue in #523.

Last suggestion before closing this for good:

Keep it coming! :)

  • ❤️1
WarningImHack3r commented

I don't have anymore idea yet but I'll surely have some once I got it finally working! :D

ivanhofer commented

Integrate every possible example (Svelte & SvelteKit with every different config basically) in your CI/CD to check if they build successfully with your latest code

That is the plan. But we haven't had time to do it until now. We did a speedrun when implementing the basics for the SvelteSummit Talk and to make the things work we show in the video the last commit was done a few hours before the event started 😅

  • 👀1