Is it fine to use the same :output-to directory for a :node-library and a :node-script target. Like so:
:builds
{:extension {:target :node-library
:js-options {:js-provider :shadow
:keep-native-requires true
:keep-as-require #{"vscode"}}
:compiler-options {:infer-externs :auto}
:output-dir "out/js"
:output-to "out/extension.js"
:exports {:activate hello-world.extension/activate
:deactivate hello-world.extension/deactivate}}
:stdio-wrapper {:target :node-script
:main :hello-world.stdio.wrapper/main
:output-to "out/hello-world.js"}
no, not fine. they will override each others files during development. for release its fine yeah
Thanks!
Would it be worth a PR to support proxying specific routes? I am running an elixir API server on localhost:4000 and setup the :proxy-url but if I visit the root URL for the devserver like http://localhost:8000 it tries to forward the request to the proxy server unless I specifically visit http://localhost:8000/index.html. Maybe we could implement something like vite's config?
{:proxy {"/api/" {:target "http://localhost:4000"
:origin true}
"/socket" {:target "ws://localhost:4000"
:ws true}}set :use-index-files in the :dev-http config (where :proxy-url is)
there is also :proxy-predicate some.ns/a-fn which points to a clj defn that gets called for all requests. true return value routes requests to the proxy, otherwise tries local
generally I recommend just not using proxy. 99% of people use it for the wrong reason, thinking it is somehow required to use :dev-http for REPL/hot-reload
just talk to localhost:4000 directly and have that serve the generated .js files
Oh thanks! Those give me what I need. My use case actually fits proxying because I frequently ssh in to work and test the webapp over tailscale. Proxying lets me hit the dev server URL and reach the API server without having to change app config every time I switch devices to swap URLs or get clever with the hostname