(Sorry about not following the template, kind of asking something different)
Since the new JS agent is very typey and nice to use, we’re considering switching to deno for various reasons which would turn this post into an ad if listed.
Has anyone done this before? If so, was it a seamless transition or were there some hurdles to overcome?
Hey 
I did try running our agent-nodejs a while ago (way before 1.0) with little to no result.
I did a few tests after seeing your post using deno@latest, and it seems like I’m able to successfully start an agent using
deno --allow-env --allow-read --allow-sys --allow-net --allow-write index.ts
This seems to lead to a working agent for a few minutes.
However, after a fews minutes, I’m getting the following error
error: Uncaught (in promise) TypeError: error reading a body from connection
This still looks promising though, so I’ll investigate further to see if this is achievable, and share anything interesting here.
Ok, so here’s where I am at:
error: Uncaught (in promise) TypeError: error reading a body from connection. Even opening a debugger doesn’t help, as it seems to be related to the inner of denoHowever:
Disabling it using instantCacheRefresh: false during the createAgent seems to do the trick 
I can’t really recommand running the agent without this though, as permissions rely on SSE to make sure they are always up-to-date (So disabling it may lead to permission inconsistency).
Just to make sure I don’t forget anything, here’s what I did:
import { env } from 'node:process'; & switched all process.env to env on the base code of the agent.createSqlDataSource, as I encountered a few typing issues when giving it the classic uri/sslMode/schema.import { env } from 'node:process';
import 'npm:dotenv/config';
import { createAgent } from 'npm:@forestadmin/agent';
import { createSqlDataSource } from 'npm:@forestadmin/datasource-sql';
import type { Schema } from './typings.ts';
try {
const agent = createAgent<Schema>({
authSecret: env.FOREST_AUTH_SECRET!,
envSecret: env.FOREST_ENV_SECRET!,
isProduction: env.NODE_ENV === 'production',
typingsPath: './typings.ts',
typingsMaxDepth: 5,
instantCacheRefresh: false,
});
agent.addDataSource(createSqlDataSource(env.DATABASE_URL || ''));
agent.mountOnStandaloneServer(Number(env.PORT));
await agent.start();
} catch (err) {
console.error(err);
}
Now that I know where to dig, I’ll check to see if I’m able to locate exactly what is causing this SSE issue, and keep you updated 
(Ok so this is a message I started on Friday - but I thought that the outcome was a bit deceptive)
Hey
Not a lot of opportunities to work on this topic in the last few days - as I spent most of my available time trying to link our typescript monorepo to a deno project to investigate further in the code.
It led to a few inconsistency in our code base, especially regarding export/export type that I’ll fix in a PR in the next few days.
With the following import map, I was able to run deno on our local dependencies - Maybe there is a better way, but I’m no deno expert …
{
"imports": {
"@forestadmin/agent": "../agent-nodejs/packages/agent/src/index.ts",
"@forestadmin/datasource-customizer": "../agent-nodejs/packages/datasource-customizer/src/index.ts",
"@forestadmin/datasource-toolkit": "../agent-nodejs/packages/datasource-toolkit/src/index.ts",
"@forestadmin/forestadmin-client": "../agent-nodejs/packages/forestadmin-client/src/index.ts",
"object-hash": "npm:object-hash",
"luxon": "npm:luxon",
"stream": "node:stream",
"uuid": "npm:uuid",
"file-type": "npm:file-type",
"antlr4": "npm:antlr4",
"fs/promises": "node:fs/promises",
"koa-bodyparser": "npm:koa-bodyparser",
"json-stringify-pretty-compact": "npm:json-stringify-pretty-compact",
"@koa/router": "npm:@koa/router",
"@koa/cors": "npm:@koa/cors",
"eventsource": "npm:eventsource",
"events": "npm:events",
"superagent": "npm:superagent",
"jsonwebtoken": "npm:jsonwebtoken",
"querystring": "npm:querystring",
"openid-client": "npm:openid-client",
"json-api-serializer": "npm:json-api-serializer",
"crypto": "node:crypto",
"path": "node:path",
"net": "node:net",
"koa": "npm:koa",
"http": "node:http",
"@fast-csv/format": "npm:@fast-csv/format",
"koa-jwt": "npm:koa-jwt",
"forest-ip-utils": "npm:forest-ip-utils",
"fs": "node:fs"
},
"nodeModulesDir": "manual"
}
(And this is today’s investigation)
Switched to loggerLevel: "Debug", hoping to get more info on what’s going on, with no luck.
Added a bunch of logs, try catches & breakpoints in our @forestadmin/forestadmin-client integration, still with no luck.
I’ll open a discussion with the team that worked on the SSE integration, just to check if it rings a bell.
(And sorry for the “devlog” aspect of the topic. As I cannot find a lot of time to work on this topic, I try to document here all my tests as much as possible).
And finally … We’re currently not compatible with deno.
Here’s the why - eventsource@2, a dependency we’re using, seems to have trouble working, especially with deno coming out of the box with a possible implementation of EventSource. This would definitely explain why instantCacheRefresh: false fixes the issue.
I quickly tried, with the import map, to switch to v3/next version of eventsource, but obviously, it seems like there are a few breaking changes, so we’ll need to investigate that further.
If possible on my end, I’ll try to switch to this new version in the following days to check whether or not it fixes the issue, and I’ll let you know.
Really appreciate the time you’re taking to look into this!
I’m happy with the devlog aspect and I hope that this endeavor is worth pursuing for your team.
Speaking of, what value do you see in supporting Deno for ForestAdmin?
Well, initially, I was mainly interested in:
Now:
.. vs ../, etc). Nothing major, but still things I’d like to be fixed 
Developer experience has been something essential in Forest Admin (We even have a feature team dedicated to this), especially with the “new” agent. So anything that could provide an even better experience for devs working with Forest is worth a try!
I’ll let you know whenever I’m able to work on this topic. Eventsource seems to have a pre-release that claims deno compatibility.
Hopefully, my next message will contain good news 
psssst nudge nudge
Apparently they have updated the library to address this issue.
Is this the typed light at the end of the tunnel?
Funny that you mention the 3.0, I was testing it this afternoon
I’m still encountering issues regarding cache synchronization, but now, agent starts & runs “as expected” (Even with local nodejs dependencies). The issue seems to be in our code this time, so … should be fixable.
I’ll do my best to book a bit of time to finalize the migration to eventsource@3, re-run a bunch of tests and I’ll let you know once everything is released.
(I didn’t mention it earlier, but this isn’t a part of our roadmap. I’m working on this topic when I can, that’s why you didn’t hear from me for a while now. Making the agent work with deno is really different from making sure that our deno compatibility can be guaranteed in the long run - and I’m still focused on the first part)
Thanks for looking into this! We’re looking at switching other parts of our stack to Deno for dev comfort and safety.
No problem on the roadmap side of things, I understand perfectly. Once/If you get it working I’ll probably switch my backoffice to Deno for a couple weeks to see how it behaves and give some feedback.