@borkdude Heyo. Following up on the requires suggestion, how about we introduce a nbb/register-feature! that gets placed in an init similar to nbb/register-plugin! e.g. (nbb/register-feature ::datascript {:requires {'datascript.core "./nbb_datascript.js"}}) ?

yeah something like that is good

We could also make it a part of register-plugin! but didn't know if you wanted to mix impl and feature concerns

This is a chicken and egg problem: since you need to load the JS first, which calls register-plugin

but the JS only gets loaded because of a require

I think it doesn't hurt if we just add the datascript namespaces into the case statement. If the JS isn't there, then you will get an error, but you would get an error when requiring those nss anyway

Ah ok. I hadn't tried this yet but happy to keep with it as is if register-feature! isn't possible

How would that work?

Where would register-feature! for datascript be called and when?

Ah. Now I understand the chicken and egg reference. It's not possible. We could also have a map in nbb.features if it helps to not have new features modify nbb.core

We could solve this maybe using a macro which using "JVM" time looks at some env variables or find all features.edn files on the classpath and merges them or so

Maybe the feature.edn idea is the cleanest, similar to data_readers.cljc

Maybe something like:

nbb_features.edn
[{:name logseq/datascript
  :namespaces [datascript.core]
  :js "./nbb_datascript.js"}
 ...
]

The macro will find all nbb_features.edn files on the classpath, and then store this in a CLJS runtime map. This map can be queried in nbb.core for feature namespaces and then call load_modules with the right stuff.

@cldwalker Does that make sense to you?

It makes sense but doing this through macros seems more complex than it has to be. We could do this within the bb task itself, generate an edn map and then slurp it in with shadow's https://github.com/thheller/shadow-cljs/blob/650d78f2a7d81f33cb2590e142ddcbcbd756d781/src/main/shadow/resource.clj#L53 during compilation

Here is an example of how you can detect the nbb_features.edn maps in a macro at compile time:

(enumeration-seq (.getResources (.getContextClassLoader (Thread/currentThread)) "META-INF"))

There are no macros or classpath thinking involved. The bb task just focuses on reading edn and generating data to an edn file

ok, if we can accomplish the same "no code diff" that way, I'm fine with that too

Cool. With any approach, there's still an entry in handle-libspecs that looks in a features map. That's fine, right?

yes, totally

@cldwalker One of the reasons why I was thinking about the classpath is that you could have several libraries floating around which contain extra features for nbb, without adding them to the central repo (for whatever reason, perhaps corporate code for example).

Then the datascript feature could live in its own dep. Adding it to your classpath would then automatically activate it. Along with a piece of shadow-cljs config which we could add via the shadow clojure API and a clojure function to build nbb

But I'm fine with proceeding on the current approach

@cldwalker About the new commits: • you will still have a git difference when you're building with features • it seems this will discover all features, not just the ones you've selected in your CI via env vars or so?