should paraglide-js avoid compiling into node_modules?

[samuelstroschein]

Vote with 👍 or 👎

Problem

The majority/all JS tooling default assumes that code in node_modules is static. Paraglide's compilation into node_modules breaks that assumption, leading to bugs that are fixed with workarounds.

Proposal

Don't compile into node_modules. Instead, compile into the source code itself with a git ignore.

-import { setLanguageTag, languageTag } from '@inlang/paraglide-js/sveltekit-example';
+import { setLanguageTag, languageTag } from '../../paraglide-js/runtime';
-import * as m from "@inlang/paraglide-js/sveltekit-example/messages"
+import * as m from "../../paraglide-js/messages"

Pros

• no need for "namespacing" as two codebases won't compile into the same directory, see paraglide-js preview feedback thread #1464 (comment)
• less bugs because the majority of tooling (typescript, bundlers, etc.) expects node_modules to be static, see Add note about Vite' Pre-bundling to build-a-global-svelte-app blog post #1533, [bug] sveltekit vercel adapter does not bundle paraglide, leading to unresolvable imports #1485 (comment), paraglide vite plugin  #1518 (comment)
• no need for declaration files as typescript can resolve JSDoc itself (simpler compiler!)

Neutral

• users are responsible for importing messages themselves (no more explaining of 'namespaces' @inlang/paraglide-js/{name}/messages; imports will differ per user (but it's just normal JS after all!))

Cons

• "pollution" of source code (gitignore to the rescue)

CleanShot.2023-11-02.at.16.37.28.mp4

[albbus-stack]

This should make it way easier to integrate with various bundlers and having a generated folder that is gitignored is really not that big of a deal these days.

[felixhaeberle]

I generally agree with this out of various reasons namely that it reduced unexpected bugs & is something the user would more likely expect.

Talking about expectations:

1. The user wants to mark this folder as "lang" or something. Namely, people are going to ask to name the source folder of the message.json "lang" and

2. name the the generated output of it "lang-generated" to ease project communication. At this point, nobody knows what's inside this paraglide-js folder & that it's generated.

Paraglide JS CLI will then become a simple --project path --import path --output path. No namespacing no nothing. Import is even optional cuz can be obtained from project.inlang.json. This will probably eliminate 99.9% of bugs.

Point being:

If we allow this, people will going to love it, because it doesn't feel alien anymore "oh this paraglide thing" but more "oh my i18n setup".

[NilsJacobsen]

I like the *-generated suffix.

[samuelstroschein]

hey guys, the messages.json is unrelated to paraglide. paraglide-js doesn't care about your source translation files. don't know what import path is supposed to be either. the cli is just --project --outdir done

[felixhaeberle]

My comment was not about the messages.json, it was about folder names & the paraglide CLI.

[NilsJacobsen]

Since there was already a big confusion around namespaces I would be happy to see this removed.

[thetarnav]

Paraglide's compilation into node_modules breaks that assumption, leading to bugs that are fixed with workarounds.

Paraglide is definitely not the only one, vite, turborepo, vitest, etc use node_modules as a place to store cached files.
But paraglide stores whats essentially source code, which I would expect to not be hidden away. Importing the library with import * as m from "../../paraglide/messages" is much more clear. When playing with paraglide initially it definitely confused me that I'm importing my messages from some node package, which caused me to believe that an extension is necessary to somehow link the generated messaged and the imported package.

It might even eliminate the need to restart ts server or reload window after updating messages and vite caching the messages, preventing them from being updated.

Also some might prefer to commit the generated code to the repository, to reduce the amount of scripts necessary to run every time you pull from the remote.

[samuelstroschein]

Agree. You raise another good argument: Transparency and Discoverability.

[samuelstroschein]

implemented