Generate TypeScript files instead of JS files?

[sbking]

I can not enable allowJs for my application because other build tooling (Remix + Vite) does not work well when allowJs is enabled. Is there any way to make Paraglide generate .ts files instead?

[samuelstroschein]

We can likely offer an option emitWithTsExtension

Can you test if changing the file endings to .ts works seamlessly in your project? Due to the JSDoc annotations, I expect TypeScript to work out of the box. If that's the case, then we don't have to use the typescript compiler which we tried to avoid to keep the complexity low

[sbking]

Unfortunately no, looks like JSDoc type annotations are only supported in JS files.

That said, I think my actual problem was that I was missing Remix's unstable_optimizeDeps flag and I think allowJs is now working fine. I think I would still prefer an option to generate .ts files to align with the rest of my codebase, but for now it's less of an issue.

[samuelstroschein]

Can confirm. TypeScript complains with "ts 80004: Please convert JSDoc to TypeScript types".

Ergh bummer. It seems like we need to run the typescript compiler with emitDeclarations only to parse the JSDoc and emit d.ts files https://www.typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html.

Good news: We won't need an option because we can emit both .js and .d.ts files. JS projects shouldn't be affected.

• Paraglide keeps being written in JSDoc

• JS projects use JSDoc (.js files)

• TS projects use declaration files (.d.ts)

@sbking are you open for a PR against the lix-integration branch that has paraglide js 2.0? Then we can include this in the paraglide js 2.0 release

EDIT: If parallel .js (jsdoc) and .d.ts files works, then we can also get rid of the entire allowJs step in the setup. That's great!

[jeiea]

Typescript language server is screwed up when modifying source files referencing inlang generated js files. It's terrible, every nextjs user should know this issue before selecting the library.

[samuelstroschein]

@jeiea, can you elaborate on the issue is you are running into? what do you mean with the ts language server is screwed up when modifying source files?

[jeiea]

If I copy/checkout ts file that transitively referencing messages.js or runtime.js, the following happens. Whenever this happens I should restart TS server. I'm not sure whether messages.js or runtime.js is root cause or not, but after I renamed messages.js to the .ts extension and noticed a noticeable reduction.

[samuelstroschein]

@jeiea can you check if this also happens if you keep the .js files and add a .d.ts file next to them? If not, then it's another argument to implement #238 (comment)

[jeiea]

It looks good, but again, I'm not sure. I can't create a 16000 line d.ts file.

[samuelstroschein]

@jeiea okay, i assume it will work. I'm adding this issue to v2.0

[jeiea]

d.ts files don't seem to support auto import, is that okay?

[samuelstroschein]

You mean having auto-complete that leads to an "auto import"?

happ...

auto completes to
 
happy_elephant()

and adds auto import 

import { happy_elephant } from "paraglide-js/messages.js"

[jeiea]

Yes. I meant that.

[samuelstroschein]

got it. i'd say we should make the d.ts compiler experimental then. people can report what mode they prefer.

also, your problem, and this issue, might be solved by #264 ? if paraglide does not compile into src, the tooling problems should go away

[jeiea]

I didn't test against the PR, i can't sure dts has problem or not now because I could make mistake when make it.

I don't think virtual modules is completely better solution, because current inlang compilation can be slow (my another issue), and I'm avoiding it by not running that compillation. I can't sure virtual module allows that.

[samuelstroschein]

Makes sense. Keeping both issues then. Users can opt for virtual modules or only emitting declarations files as they seem fit.

[samuelstroschein]

@skbing #273 should solve this issue

[samuelstroschein]

Paraglide JS 2.0 will have an experimentalEmitTsDeclaration flag. During the development of the flag it became clear that generating TS files directly is the way to go. I opened #299 as follow up

[samuelstroschein]

Argh... the experimental emitTs directly flag leads to too much overhead.

• Paraglide needs to rewrite paths
• Every function is implemented twice in JSDoc and TS
• Writing adapters requires dual declaration of JSDoc and TS as well

I considered emitting only TS but that would negatively impact the majority of projects:

• build time get's longer (which can be an issue see Astro integration broken #313) because TS files need to be compiled into JS
• virtual modules would need to compile TS to JS as well

Current thinking is:

1. Keep emitting JSDoc because it works for >90% of use cases, is simpler, plus runs anywhere (it's just JS)
2. Re-introduce the emitTsDeclarations flag for rare cases where direct TS usage is needed

Thoughts?

[minht11]

I have been using experimentalEmitTs and I liked it, but for my cases emitTsDeclarations would also be enough.

[samuelstroschein]

emitTsDeclarations is doable. Slows down the compiler by 2x but if you can't set allowJs in your project, it's reasonable.