usage: how to run farrow with `esno` ?
yolio2003 opened this issue ยท 13 comments
- Can't find the entrance to run farrow separately, can't it run independently without farrow cli? (It seems that there is only one more generation step)
- The default interface generated by farrow cli will automatically send a request. Is there a configuration to turn off this? cause it looks weird.
- how to get a esm verion of
farrow-api-client
, so i can use it quickly
Can't find the entrance to run farrow separately, can't it run independently without farrow cli? (It seems that there is only one more generation step)
You mean the node.js api of farrow
?
It can be used like below.
import { build } from 'farrow/dist/build'
import { start } from 'farrow/dist/start'
import { dev } from 'farrow/dist/dev'
await build({...config})
The default interface generated by farrow cli will automatically send a request. Is there a configuration to turn off this? cause it looks weird.
This feature can be turned off.
// farrow.config.js
module.exports = {
// for connecting farrow-api-server and codegen farrow-api-client
api: [
{
src: 'http://localhost:3002/api/todo',
dist: `${__dirname}/src/api/todo.ts`,
codegen: {
/**
* emit createApiClient or not
* if set to false, only types will be codegened
*/
emitApiClient: false
}
},
],
}
But why do you want to turn off it? It's very useful for communicating with the server automatically.
how to get a esm verion of farrow-api-client, so i can use it quickly
There is no explicit plan for ESM support. We used to emit ESM version but encounter some wired bug in node.js/webpack/esbuild toolings and can figure out what's happening, so we turn off it.
When the js/ts community is ready enough for ESM modules, we will enable the feature.
got it , thx master,
for "1" looks it has some error tips, maybe should provide a more easy way from source not dist.
for "2" cause it just a bit noise for me. already done now, thx.
for "3", i mean only wana have the farriow-api-client ems version as chrome already support importmap, so we can use this in client quickly.
for "3" maybe not esm version iife version is ok too.(in face i can use vite to compiled this.)
@yolio2003 farrow-http v1.10.10
had released a new feature that will disable introspection request log
by default.
Try it out~
got it thx! i think you can do this in 10 seconds by default, if you want to show the feature.
hey boss, i have successly run with node --experimental-loader esbuild-node-loader ./src/index.ts
, and i haven't get error during running process.
then i found that
- server bundle to CJS will get some error, i can ignore this, cause i use esbuild-node-loader, and it works well
- so i tried just use client complied, i found that it deps on api, but it also scan the
src/index.ts
and trigger some error, that is not necessary! - however, finally i change code to run this, but it's bad DX,
so the idea is can we just complied from the src/api/
so i can move the error deps (like lowdb ...) from /src/api
to /src/index.ts
, then i think everything should works well ?
sorry for nagging again.
Does here need two build outputs, commonjs and esm?
@yolio2003 Are you trying to use farrow-http
as ESM Modules? It currently does not support ESM..
Does here need two build outputs, commonjs and esm?
no, just need emitApiClient to be correct.
@yolio2003 Are you trying to use
farrow-http
as ESM Modules? It currently does not support ESM..
yes, i run with node --experimental-loader esbuild-node-loader ./src/index.ts
, it works very well (i can ignore import issue)
can we only deps on /src/api
? cause i need to do this:
- run my app with esbuilder
- remove the
import from "lowdb"
remove the not support syntaxawait __dirname ...
- modify and fix
import issue
- run
yarn run dev
> a. start server >b.build to /client/todo.ts
> c. synced/client/todo.ts
- fallback step 2
so the question is, should the clientApi step should only deps on these ?
http://xxx.com/todo
/src/api
type define
Sorry, we suggest to run farrow app
via official tooling like farrow-cli
.
It will be a mess if we try to support ESM now. Maybe in the future that the ecosystem is more stable, and the tools around ESM support are more complete, it is time for us to move forward the ESM way.
ok just discuss the clientApi codegen's dependences. that's ok.