Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-02-11

Channels

#shadow-cljs
<
2023-02-11
>
borkdude19:02:58

Is there a way with target esm to emit .mjs files rather than .js files? I have a project which requires the entry point to be a cjs .js file

thheller19:02:35

not currently no

borkdude20:02:51

we almost got the electron thing working with target esm, but the entrypoint file must be a cjs file with the .js extension

thheller20:02:14

its ok to write some boilerplate JS code if needed 😉

thheller20:02:14

I guess I'm confused by your statement. I mean it might be ok to write that cjs file yourself in JS and just call out to the ESM code?

borkdude20:02:58

yes, believe me, I've written some boilerplate. but the entrypoint must be a file which cannot end with .cjs

borkdude20:02:21

and because of target esm we must state "type": "module", which means every .js file is an esm file

thheller20:02:08

does the trick work to put the ESM output into its own folder with its own package.json type module

thheller20:02:15

but at the root just a regular package.json without?

thheller20:02:53

or you just rename the .js files to .mjs 😉

thheller20:02:39

did you try the separate folder trick? I'm not sure how type:module is handled for sub dirs, or if its only recognized at the root

borkdude20:02:07

do you mean, put a package.json in the out directory?

borkdude20:02:37

that seemed to work!

👍 2
borkdude21:02:07

If I define a global like: 

globalThis.joyride_vscode = require("vscode");
(for reasons...) and refer to it from CLJS as: 
(def vscode js/joyride_vscode)
and then do: 
(vscode.window.showInputBox ...)
how can I prevent advanced renaming these usages

borkdude21:02:28

I tried an externs file like: 

global:joyride_vscode
window
showInputBox
createOutputChannel
showInformationMessage
but this gets a bit tedious

thheller21:02:59

this vscode.window.showInputBox may just loose the necessary type info, did you try with proper interop?

thheller21:02:20

or maybe (def ^js vscode js/joyride_vscode), although that should be inferred

borkdude21:02:32

trying the latter now

thheller21:02:39

(.. vscode -window (showInputBox ...)) might work, although I remember something about .. not preserving typehints

thheller21:02:08

the whole symbol with dot handling is a bit hacky in many places

borkdude21:02:23

maybe it also helps to define a .js file and then import vscode from that .js file which retrieves the global?

borkdude21:02:27

It did work before with (:require ["vscode" :as vscode]) with the same interop

thheller21:02:32

why are doing this in the first place? (:require ["vscode" :as x]) x/window.showInputBox should properly infer

borkdude21:02:33

because the cjs + esm hack we're now in, gave us "cannot find module vscode" errors, I think because in vscode, that module is implicit

thheller21:02:02

who cannot find it? shadow-cljs or vscode?

borkdude21:02:38

let me get back to you later, I need to go for a moment

borkdude22:02:01

@U05224H0W It seems vscode itself has problems with it:

thheller22:02:45

hmm yeah. no clue

borkdude22:02:25

So this as workaround helps, I think: src/joyride/vscode.js 

module.exports = globalThis.joyride_vscode;
and then: 
["/joyride/vscode.js" :as vscode]

borkdude10:02:25

Do you happen to know where this error might be coming from in watch mode? 

Activating extension 'betterthantomorrow.joyride' failed: WebSocket is not defined.
My workaround for this is: 
globalThis.WebSocket = require("ws");
in the main wrapper, but I wonder if there's a better solution

borkdude10:02:30

I made it conditional like this now: 

ws_file = require.resolve("ws");
if (ws_file != null) {
  globalThis.WebSocket = require(ws_file);
}

thheller10:02:10

:target :esm assumes that it is executed in the browser runtime by default

thheller10:02:14

haven't written the node runtime yet

thheller10:02:38

so it would be :runtime :node in the build config, but thats not implemented

borkdude10:02:43

It does work well with the ws library though, hot reloading in the electron extension "just works" :)

thheller10:02:34

good to know

borkdude10:02:34

In fact, the only places where I've used target esm was in Node.js so far