Fork me on GitHub
#cljs-dev
<
2017-10-11
>
dominicm08:10:49

I think it would be useful to have a feature to allow control over "where" resolution for a build. Discussed previously was that you get issues with the current design of "if it's in node_modules, just use that" in case you're separately building a frontend project in the same directory OR you have multiple builds within the same JVM of which you want to have different behaviour.

thheller09:10:03

I solved this in shadow-cljs by adding a :resolve config which basically allows “redirecting” what a certain (:require ["thing" :as x]) does by name

thheller09:10:07

:js-options
{:resolve
 {"react"
  {:target :npm
   :require "react/cjs/react.development.js"
   :require-min "react/cjs/react.production.min.js"}

  "react-dom"
  {:target :npm
   :require "react-dom/cjs/react-dom.development.js"
   :require-min "react-dom/cjs/react-dom.production.min.js"}
  
  "jquery"
  {:target :global
   :global "jQuery"}

  "something"
  {:target :file
   :file "some-path/to/file.js"}}}

thheller09:10:14

totally agree that there should be something like this in core since its per-build (which deps.cljs is unsuited for)

thheller09:10:41

:js-provider is also useful, since a :node-script will pretty much always want to use direct require

Roman Liutikov08:10:02

Is it a known problem that during incremental compilation paths to scoped NPM packages (`@scope/pkg-name`) are being lost? Happens after very first re-compilation.

Roman Liutikov08:10:14

Getting the following error at runtime: Undefined nameToPath for path/to/npm/pkg

Roman Liutikov08:10:52

Happens with NPM packages defined in deps.cljs in dependencies.

dnolen16:10:34

haven’t heard that, create something minimal and file a ticket

juhoteperi17:10:58

@mhuebert Hmm, at least :compiler-options :foreign-libs should take precedence over dependencies, I thought local deps.cljs would also work