New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move Langium to ESM #905
Comments
I assume that would be for version 2.0? |
Yes, we should try to target this for a version 2.0 of Langium. It shouldn't be too much work, but we need to ensure that it's supported in vscode/theia. |
On the user side, I tried to convert bytescript type:module in package.json. I was able to get the cli to work (the project is bootstrapped from the hello-world example, and follows that setup). The cli generator loads and uses Langium APIs fine. Here's what I did: The first problem is easy to fix: import specifiers should have file extensions appended to file names, f.e. F.e. based on the hello-world template, in the import { ByteScriptAstReflection } from './ast.js';
import { ByteScriptGrammar } from './grammar.js'; For testing, I modified these generated files by hand after Then the #!/usr/bin/env node
import run from '../out/cli/index.js'
run() Package.json needs something like the following with the extension included: "bin": {
"bytescript-cli": "./bin/cli.js"
}, Then I then went through all the project TS files and added all the The import * as vscodeUri from 'vscode-uri'
const {URI} = vscodeUri Lastly, in import fs from 'fs'
const relative = (path: string, base: string) => new URL(path, base).href.split('file://')[1]
const pkgFile = relative('../../package.json', import.meta.url)
const pkg = JSON.parse(fs.readFileSync(pkgFile).toString()) The CLI's generate function works. I pushed this example to this branch: https://github.com/bytescript/bytescript/tree/langium-issue-905 including the generated files committed, which are normally gitignored. After cloning and checking out that branch, running However at this point, trying to run the extension for debugging ( So VS Code will have to change this to be an |
I believe the last piece to get this working is to use the wonderful https://github.com/abbr/deasync However, it seems to not be built for Apple silicon yet, so I can't test on my MacBook at the moment. Essentially replace const deasync = require('deasync')
// Make an import wrapper in the callback format that deasync supports.
function importSyncImpl(specifier, callback) {
import(specifier)
.then(mod => callback(null, mod))
.catch(err => callback(err))
}
// Wrap it into a synchronous function.
const importSync = deasync(importSyncImpl)
// This blocks until the import resolves, without `await` (no top level `await` in CommonJS):
module.exports = importSync('./out/extension.js') Here's a new branch implementing this: https://github.com/bytescript/bytescript/tree/langium-issue-905-2 After If it does, this effectively means that all user code is ESM except for this one file that VS Code |
There are a couple of forks of deasync, @kaciras/deasync and wdeasync, with prebuilt binaries for mac, but it seems to hang for me on this M2 macbook. Ah well. I suppose waiting for VS Code (Electron) to officially support ESM might be the most viable. |
I've readded this to the v2 milestone again. I've been testing out making Langium an ESM library and using |
With the general available ESM support in all major browsers and Node.js, we should consider moving to ESM ourselves.
One of the reasons we've shied away from that was the lack of ESM support in the VSCode extension host. As VSCode is starting to migrate to ESM, we should move along.
The text was updated successfully, but these errors were encountered: