Feature: Compiler versions

[aehlke]

Type of feature

✨ Feature

Current behavior

No response

Suggested feature

Example use case: Svelte 4 compiler is currently bundled; Svelte 5 beta is active but will require migration to use. LiveCodes should be able to pin to the version 4 compiler (just as an example of a more general request) as well as introduce the v5 compiler without breaking older configurations or requiring maintaining diff versions of livecodes to compile diff projects.

(It'd also be nice to have this as a way to use beta compilers like Svelte 5)

Additional context

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Contributing Docs

• [x] I agree to follow this project's Contribution Docs

[hatemhosny]

This needs some thinking...

I can see the need (specially with the upcoming incompatible svelte 5).

However, different compiler versions may introduce different compile API. So it might not just be a change in version number. It may also be different code that we need to maintain for each version. For example, vue 2 is treated as a different compiler than vue 3.

In some compilers (e.g. react jsx), react version can be specified in the import like:

import React from 'react@17'

But in most others, we need to maintain the code for compiler. This can be manageable in a specific playground (e.g. svelte playground), but in LiveCodes, having to maintain that for 87 different compilers would be a maintenance nightmare that would not scale.

So, the strategy now is to provide the latest stable version of each compiler. The version number for the running compiler is documented in the language docs: https://livecodes.io/docs/languages/ Example for vue: https://livecodes.io/docs/languages/vue#version

For backward compatibility of user code, it is recommended to pin LiveCodes app & SDK versions with permanent URLs as documented here: https://livecodes.io/docs/features/permanent-url

Let's keep this issue open for now, till making up my mind.

[aehlke]

Pinning old versions of Livecodes as standard practice to avoid user code from breaking sounds like a security risk if Livecodes ever needs a security update without there being an upgrade path that doesn't require rewriting the user code (compare with say Xcode, where it continues to be able to build old versions of the Swift toolchain while receiving security/feature updates as an IDE, or where it has flags for setting the language version of the C/C++ compilers)

Perhaps requiring the latest stable release works well most of the time but major fractures such as with Vue get their own "duplicated" compilers for v2 / v3, maybe avoiding promoting old versions within Livecodes. Luckily I noticed Svelte5 will be backwards compatible with Svelte4 components so that's not actually an issue (besides interest in a beta channel for compilers).

edit: another option is to give users the ability to provide a 'plugin' without forking livecodes that has the compiler setup completely such that users can make their own decisions on what compiler specifics to have (beyond the config param currently existing) and share that work with the community, without requiring you to maintain. For example, to be able to easily show off a beta channel which can otherwise be hard to get people to try compared with stable versions

[hatemhosny]

I like the idea of plugins. This is something I can explore.

[aehlke]

Especially nice if you release your own compilers as plugins so that making a community plugin is as simple as forking a file or repo.

Plugins will also be concise enough to include a sample one plus a user input to generate it via AI (OpenAI or local LLM, such as https://github.com/rahuldshetty/llm.js or https://huggingface.co/docs/transformers.js/index ) if fed some more context like specific version of docs for target compiler

[hatemhosny]

The basic language specs (compiler + formatter) can be as simple as this (markdown)