shadow-cljs 2022-08-19 | Slack Archive

Would there be straightforward way to automate an edit to package.json for specific build(s)?

Case is a generic template for development of VS Code extensions using a repl. An extension must be "activated" to create the environment the repl should run in. Code lazily activates extensions, and only under specified conditions, such as for a certain language or after User runs a command provided by the extension. The author must whitelist events to trigger activation in package.json. There is a * option, which tells Code to just activate after any possible activation event, which roughly translates to ASAP. An extension only needed in limited cases should avoid using *, because that slows startup for no reason. However while developing in cljs, it would usually be the best option, to ensure the js repl is available straight away, without awkward steps between building and repl-ing. So it would be great to be able to declare * activation event only for a particular dev build, while still using the rest of package.json as written, and still allow writing more specific activation events that would apply otherwise.

thheller06:08:11

I'd say to build this yourself. Just make a command in the REPL that edits package.json the way you want. or create it as part of however you launch the watch. so maybe npm run dev or whatever and the proper "scripts"

thheller06:08:52

there is nothing in shadow-cljs to do this and I can't think of anything that would be easier to do than just doing it yourself

👍 1

mccraigmccraig13:08:21

i'm having an issue with an expo/react-native app compiled with shadow-cljs atm ... production builds are working fine, but watch builds are failing on the device with an error like: Error: Unable to resolve module ./app/goog.math.long from /Users/mccraig/dev/employeerepublic/repos/yapster/yapster-app/app/.: interestingly, i note that we had to use: "entryPoint": "./index.js" in our expo app.json, instead of the "entryPoint": "./app/index.js" suggested by the shadow-cljs user guide and i'm wondering if these things are connected has anyone seen anything similar ?

thheller16:08:16

@mccraigmccraig are you sure that device has the same output? I mean could just be an easy path mixup? in the above error it is trying to find /Users/mccraig/dev/employeerepublic/repos/yapster/yapster-app/app/app/goog/match.long.js? seems to have a duplicated app?

mccraigmccraig16:08:51

i'm not sure where the app in app/goog.math.long is coming from actually... and we have a yarn workspace setup which might be messing things up too... the error messages from expo/metro are often not very informative, so i'm going to strip things back to a basic setup which works and move forward from there

thheller17:08:19

well just grepping for app/goog.math.long in your project should tell you where its coming from

mccraigmccraig18:08:19

app/goog.math.long doesn't appear in any of the source...

mccraigmccraig18:08:58

but it turns out that it's hermes related - disabling hermes makes the watch builds work fine again

mccraigmccraig18:08:37

the release builds are fine with hermes (which does make a massive cold-boot time-saving)

mccraigmccraig18:08:40

there's definitely something about our packaging which is triggering the issue though - 'cos enabling hermes on the expo-reagent-demo does not seem to break watch builds

alex18:08:51

Would you suggest this approach for breaking out browser vs. node code? This is related to having host-specific impls for SSR https://gist.github.com/thheller/fa044450a6470fdd1afdbcf3f37a65e3 For browser, I'll have something like

:modules {:browser {:entries [components.host-specific.browser]
                                              :init-fn components.host-specific.browser/init
                                              :depends-on #{:shared}}

Is it possible to get something up like this for the node-library target? I want to have the Node side call a similar node-specific init fn

thheller18:08:07

for :node-library you can do it via :exports-var I guess

thheller18:08:06

(def my-exports (do (whatever-init-you-want) #js {:foo "bar"}) and :exports-var that.ns/my-exports

👀 1

alex18:08:19

At the moment we have that exports-var set to export an object of Firebase cloud functions. Is there a nice way to merge exports? Are :exports-var , :exports-fn and :exports mutually exclusive, or can they be used together?

thheller18:08:53

don't really need any of the others if you have :exports-var since that can do everything you could possibly need?

thheller18:08:13

just move whatever you have in the config to that var

alex19:08:42

Thanks!

alex19:08:18

Seems to be working like a charm! Wish I had gone with this approach earlier 🙂 Feels a lot more manageable than the .cljc files and browser/node reader conditionals I originally went with

👍 1

winsome20:08:43

I've connected my editor to a :node-library build and I'm getting a No available JS runtime. error. The troubleshooting docs have a section on the :node-script and :node-library targets, but I'm not sure what it means to "run" a library in a node process.

2022-08-19

Channels