Next step will be to add some caching. E.g. you could write the hash into node_modules after install and check next time to skip npm install

I did end up just going with devDependencies for the final script 😛

It could work (with some tweaks at least) but you don’t probably want to run npm install on each lambda cold-start.

Agreed. I think the above is a hack when you don't want to acknowledge that your project just needs a package.json with some (dev) deps in it (but a cool hack nonetheless)

trying to load my library https://github.com/lilactown/cascade/ results in an error

Welcome to nbb v0.6.129!
user=> (require '[cascade.core])
"#error {:message \"Could not resolve symbol: object\", :data {:type :sci/error, :line nil, :column nil, :file \"/Users/lilactown/.nbb/_deps/716b236931c25c4538fd4b1d97caa046376f4e51/nbb-deps/cascade/core.cljc\", :phase \"analysis\"}}"

the offending line(s): https://github.com/lilactown/cascade/blob/ad3a92128de0eb5a633a0043874d8744626333d7/src/cascade/core.cljc#L491-L498

actually boiled it down to a more general issue with extending protocols https://github.com/babashka/nbb/issues/242

Thanks. This needs to be fixed in SCI

I've found another problem with protocols in nbb that needs to be fixed in SCI

Thanks

Heads up: I'll look into your PRs on Wednesday or Thursday

sounds good! thanks for the communication. I'm still hacking a bit

I didn't look closely enough yet, but instead of introducing another multimethod: another idea might be to register something on the protocol var: like, this protocol extends these registered types. I think I'm already doing that somewhere, not exactly sure, but you'll see it in the satisfies? implementation if it's still there

yeah I think that makes more sense too

I'll try that

the only time I think we need to do that is for extending default in CLJS and Object in CLJ, to differentiate between "this has protocol does not match this object" and "this protocol matches every object"