Missing $lib/paraglide from skeleton project

[pe1uca]

When creating a project using bunx sv create new-project and selecting the options below, the app doesn't run with error ENOENT: No such file or directory

This seems to be because the project doesn't include the files necessary inside src/lib/paraglide which are referenced in the vite.config.ts file.
After commenting the paraglide plugin and the references in the project it can properly start.

┌  Welcome to the Svelte CLI! (v0.5.11)
│
◇  Which template would you like?
│  SvelteKit minimal
│
◇  Add type checking with Typescript?
│  Yes, using Typescript syntax
│
◆  Project created
│
◇  What would you like to add to your project? (use arrow keys / space bar)
│  prettier, eslint, vitest, playwright, tailwindcss, drizzle, lucia, paraglide
│
◇  tailwindcss: Which plugins would you like to add?
│  forms, container-queries, aspect-ratio
│
◇  drizzle: Which database would you like to use?
│  PostgreSQL
│
◇  drizzle: Which PostgreSQL client would you like to use?
│  Postgres.JS
│
◇  drizzle: Do you want to run the database locally with docker-compose?
│  Yes
│
◇  lucia: Do you want to include a demo? (includes a login/register page)
│  Yes
│
◇  paraglide: Which languages would you like to support? (e.g. en,de-ch)
│  es,en
│
◇  paraglide: Do you want to include a demo?
│  Yes
│
◇  Which package manager do you want to install dependencies with?
│  bun

[AdrianGonz97]

Unfortunately, I'm unable to replicate the issue with the provided selections. Can you trim it down to only the minimally reproducible portions (i.e. only selecting paraglide rather than every add-on) and providing a link to a reproduction repo?

[pe1uca]

Same thing with minimal options selected, here's the link to the repo https://github.com/pe1uca/testSvCreate

┌  Welcome to the Svelte CLI! (v0.5.11)
│
◇  Which template would you like?
│  SvelteKit minimal
│
◇  Add type checking with Typescript?
│  Yes, using Typescript syntax
│
◆  Project created
│
◇  What would you like to add to your project? (use arrow keys / space bar)
│  paraglide
│
◇  Which languages would you like to support? (e.g. en,de-ch)
│  es,en
│
◇  Do you want to include a demo?
│  Yes
│
◇  Which package manager do you want to install dependencies with?
│  bun
│
◆  Successfully setup integrations
│
◇  Successfully installed dependencies

[geko1971]

@pe1uca I experienced the same issue, but it was eventually simply the fetch of inlang plugins from https://cdn.jsdelivr.net failing at compilation time.

When running pnpm dev I got several errors like the following:

ERROR  Couldn't import the plugin "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-empty-pattern@1/dist/index.js":

ModuleImportError: Couldn't import the plugin "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-empty-pattern@1/dist/index.js":

TypeError: fetch failed

I solved by disabling SSL verification for the process as a workaround.

HTH...

[dominikg]

you can load the inlang plugins from node_modules via fs path instead. just install the packages for them as devDependency.

[waedi]

you can load the inlang plugins from node_modules via fs path instead. just install the packages for them as devDependency.

Can you give some more detailed instructions, please? I am pretty new and cannot get it to work.
bun add complains about blocked postinstalls and the provided steps to solve those don't work either.
Then I also do not know where I have to load the inlang plugins.
Maybe I should abandon bun for the moment.

[manuel3108]

Since this seems to be problematic for at least 3 users , we should check if we can find another way to do this.

[paoloricciuti]

you can load the inlang plugins from node_modules via fs path instead. just install the packages for them as devDependency.

Can you give some more detailed instructions, please? I am pretty new and cannot get it to work. bun add complains about blocked postinstalls and the provided steps to solve those don't work either. Then I also do not know where I have to load the inlang plugins. Maybe I should abandon bun for the moment.

Yeah I actually did it for job and you have to patch the package to remove the post install.

Curiously they basically just read the file and eval it instead of actually importing it so if you really want I guess you could include it just as a copy pasted file

[dominikg]

you add this in paraglide settings.json instead of the jsdelivr urls

	"modules": [
		"node_modules/@inlang/message-lint-rule-empty-pattern/dist/index.js",
		"node_modules/@inlang/message-lint-rule-identical-pattern/dist/index.js",
		"node_modules/@inlang/message-lint-rule-missing-translation/dist/index.js",
		"node_modules/@inlang/message-lint-rule-without-source/dist/index.js",
		"node_modules/@inlang/message-lint-rule-valid-js-identifier/dist/index.js",
		"node_modules/@inlang/plugin-message-format/dist/index.js",
		"node_modules/@inlang/plugin-m-function-matcher/dist/index.js"
	],

and you have to install each of the ones you need as devDependency. To prevent them from executing scripts you can use pnpms onlyBuiltDependencies or neverBuiltDependencies feature or just disable all post-install scripts (thats a safer environment but you might have some deps that depend on it working, put those in onlyBuiltDependencies then

https://pnpm.io/package_json#pnpmonlybuiltdependencies

[mquandalle]

Probably fixed by #461 ? @samuelstroschein

[manuel3108]

No, i don't think this should have solved it. v2 did dramatically reduce the number of required modules though, which was our initial concern for not adding each package to the users package.json. Installing the packages locally and using @dominikg's suggested solution, should solve this problem once for all.

[samuelstroschein]

Adding context on why Paraglide JS fetching modules on the fly:

• We can't build an NPM dependency into inlang/paraglide because inlang apps run the in the browser and inlang works for iOS, Android etc too.

• Modules are cached as file locally (so only the initial fetch needs to work)

Fetching modules on the fly is annoying if issues like this one pop up. So what's the solution?

Standalone .inlang files that can install plugins locally "into the file". opral/lix-sdk#241 describes the approach for lix (which the inlang file format uses). Standalone something.inlang files is the direction we are going to push for long-term to solve hand-offs, installing plugins, running in the browser, etc.

You likely read this and think "but how do i store this in git then?". That is to be determined. Likely git ignoring the binary file and fetch it from a host/google drive on build is the way to go. Unfortunately, git is unsuited for anything binary and running in the browser, etc.. We learned this the hard way.

[dominikg]

i still believe it should be more straightforward/simple to use inlang plugins from npm.

you could either make both ways first class citizens or change the internal/web usage to sth like esm.sh which even supports import maps. https://esm.sh/#docs.

[samuelstroschein]

Why would esm.sh be better than the current approach?

Inlang plugins are loaded from disk. If the plugin does not exist on disk, it's fetched from the link, written to the disk, and then loaded. The unexpected behavior for node devs comes from "why can't I npm install?". Answer: Because NPM install doesn't work in the browser, NPM is not used outside of node, and a dependency on NPM/Node is way to overkill for a file format.

ESM.sh would always do HTTP imports and never read from disk. That seems inferior to the current approach?

[mquandalle]

The unexpected behavior for node devs comes from "why can't I npm install?".

It's also npm update. During the v2 beta I had an obscure bug with an incompatible file format, tried multiple times to update all packages to their latest version until I realized that I had to modify the modules field of project.inlang/settings.json. It's a strong expectation for a JS developer, that updating your package.json is all you need to update your dependencies, I don't see a compelling reason to break that expectation.

[samuelstroschein]

It's a strong expectation for a JS developer, that updating your package.json is all you need to update your dependencies, I don't see a compelling reason to break that expectation.

But we are developing inlang for anyone in localization pipelines (designers, translators, product managers, developers, ...).

NPM install and the package.json straight-up excludes the majority of people involved in localization. Even looking only at developers, only a small subset (NodeJS developers) use NPM installl/package.json. iOS Android, Flutter devs are all not using NPM.

I just intended to provide context. We are not moving our decision to build a dependency on NPM. I understand that it's desirable for a minority of developer that use inlang. But, as mentioned, the long-term goal is to make an inlang file portable anyways with 0 dependency on node modules, package json, git, or anything else to make localization simple across everyone who is involved in localizing software.