'baml-cli generate' supports ES Module

[lanluu]

Currently, baml-cli generate creates .ts files such as globals.ts containg the following import:

import { getBamlFiles } from './inlinedbaml'

Compilation in module type can cause error, as the resolve without file extensions .js cannot executed.

How can I force baml-cli generate to create the import with file extensions i.e. import { getBamlFiles } from './inlinedbaml.js'?

[hellovai]

oh that's a great request. We should really just support raw js as a generation type and that would solve this problem i think. I'll take a look at when we can do this (it should be low effort)

Meanwhile, I think your workaround would be:

1. have a seperate local package that in your node project that contains your baml code
2. import your code from that local package

[lanluu]

I think i did it but it does not work out.

So, i have the following struture:
(1) Package P1: contains baml_client and my code calls to functions given by baml_client -> I build it with tsc and pack dist folder.

import { b } from '../baml_client/async_client.js';
...

(2) Main Project (NestJs) -> import .js file from Package P1 -> By running via nest start, the mentioned error still appears:

Error [ERR_MODULE_NOT_FOUND]: ....
baml_client/globals imported from .... /async_client.js
at finalizeResolution (node:internal/modules/esm/resolve:257:11)
    at moduleResolve (node:internal/modules/esm/resolve:914:10)
    at defaultResolve (node:internal/modules/esm/resolve:1039:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:554:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:523:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:246:38)
    at ModuleJob._link (node:internal/modules/esm/module_job:126:49)

Or did you mean that at (2) I should import the whole Package P1?

[aaronvg]

yes at (2) you should import the whole package. Basically you can just build a standalone package with your baml client and then add it to the package dependencies in package #2. You can use something like npm or pnpm workspaces. The problem is just hot-reloading, and the development cycle is going to be longer. Perhaps we can add a flag to the generator block to add .js to the file imports.

[lanluu]

Thank you @aaronvg @hellovai for your tips. I will give it a try tonight.
I wish you guys will add such configuration for generation soon. :-) (y). Really love BAML.

[lanluu]

I confirm it worked.

[jkonowitch]

oh that's a great request. We should really just support raw js as a generation type and that would solve this problem i think. I'll take a look at when we can do this (it should be low effort)

Meanwhile, I think your workaround would be:

1. have a seperate local package that in your node project that contains your baml code
2. import your code from that local package

ESM is especially important for Deno. At the moment, you must deno run --unstable-sloppy-imports in order for the modules to be resolved.

What would raw js generation achieve? And I'm assuming type definitions would still be generated?

(FYI workaround for now, ensure

{
  "deno.unstable": ["sloppy-imports"]
}

is in your .vscode/settings.json to get IDE type completions
)

[jkonowitch]

One other complicating consideration here: Deno enforces the correct file extension, so in the case of a typescript file it expects:

import type { Checked, Check } from "./types.ts"

Whereas in node, you would use

import type { Checked, Check } from "./types.js"

Even for typescript files. (Because when using node.js everything is ultimately transpiled to js, whereas that is not the case in Deno)

One alternative, instead of making baml deal with this:

deno lint --unstable-sloppy-imports . --fix will fix all of the file extension issues - this could easily be run after baml-cli generate in Deno projects. Just a thought to minimize complexity of the library.