If I understand correctly the short answer is: no. I chose this setup specifically to avoid anyone ever putting compiled CLJS code in npm packages. The problem with this would be that everyone would bring their own cljs.core version again.
That is an issue currently when you write a npm package in CLJS and publish to npm. Each package contains its own conflicting version of cljs.core (and maybe others) even if you compile with :advanced. All CLJS sources must be compiled with the same CLJS compiler, you cannot use a precompiled "some-package/cljs.core.js" as there is no way to guarantee that everyone was using the same version and so on. The way npm resolves version conflicts is by creating nested node_modules folders. ./node_modules/A ./node_modules/shadow-cljs (v1.0) ./node_modules/B ./node_modules/B/node_modules/shadow-cljs (v1.1) and so on. There is no way to ensure that B uses the same shadow-cljs version as A. By not having any compiled CLJS code in any npm package we can sort of get away with it though. See: https://docs.npmjs.com/how-npm-works/npm3-nondet https://docs.npmjs.com/how-npm-works/npm3-dupe yarn fixes some of these issues but not all. I do however think that it would be relatively straightforward to put uncompiled CLJS code into npm packages and have them picked up by shadow-cljs. So if you have ./fancy-package/src-cljs/fancy/foo.cljs You could just require("shadow-cljs/fancy.foo") and (:require [fancy.foo]) to use that. While you can still require("fancy-package") normally if there also was JS code but never require("fancy-package/fancy.foo"). It's a bit confusing but I repeat: there must never be compiled CLJS code in a npm package, only uncompiled .cljs files just like we do in CLJS .jar files published to clojars (or maven). For now I do recommend using the normal CLJS methods to publish CLJS libs. Publishing to npm would be something only currently supported by shadow-cljs and that would not be a good idea (for now). Things need to be ironed out first. I cannot explain this very well, as I am still very confused about it myself. Sorry if you wanted something completely different. On Tuesday, May 16, 2017 at 7:54:41 PM UTC+2, Jiyin Yiyong wrote: > Fascinating.. it's using `node_modules/shadow-cljs` to do the trick. I can > see ClojureScript files are compiled into CommonJS compatible form... > > > Do you think it's possible that we put all js built from `cjs.core`(also with > `goog`) into a single npm package. And then for each ClojureScript file, it > is mapped to a JavaScript file by `shadow-cljs` tools, which use > `require("./cljs.core.js");` to access it's cljs dependencies(like in your > demo), and use `require('package_name/foo/bar')` to require sibling files. > For other packages, maybe we can do the some trick, like precompile them with > `shadow-cljs` tools and then release them to npm. Seeing from a CoffeeScript > user, I think somehow in this way ClojureScript can also fit into npm's > ecosystem. > > > Here's an example, we may create a new project in such file structure, where: > > > `src/` is for source code, > `target` is for compiled code, > `package.json` is copied from `assets/package.json` to `target/package.json`, > > > ``` > . > ├── assets > │ └── package.json > ├── project.clj > ├── src > │ └── demo > │ └── main.cljs > └── target > ├── demo > │ └── main.js > └── package.json > ``` > > > if it's in this way, `target/` can be released on npm as a module and others > surely may use `require('package_name/demo/main.js')` to load the package > built from ClojureScript. > > > > > > > On Wed, May 17, 2017 at 12:15 AM Thomas Heller <th.h...@gmail.com> wrote: > > > > 1. Should we call this "cljs-require"? With the understanding that it is a > > bit like a portal to cljs's ":require" form: > > > > > > require('cljs-require/foo.core') > > > > The package name must be something you add to your package.json, otherwise > yarn will nuke the directory every time you run "yarn install". "npm" isn't > as strict but still. Using the name of the tool seemed like the obvious > choice. We can however create an empty cljs-require npm package that just > serves as a placeholder. > > > > I'm totally for this if other tools want to adopt this idiom. I definitely do > not want this to be something you can only do with shadow-cljs. > > > > > > > 2. Is there a way to set the ClojureScript version, or is it tied to > > shadow's version? > > > > You can specify dependencies in package.json, basically like you would in > lein. > > > > "shadow-cljs: { > > "version":"1.0.20170516", > > "dependencies": [ > > ["org.clojure/clojurescript", "1.9.542"] > > ] > > } > > > > where "version" is the version of shadow-devtools, any other dependencies are > resolved using the fantastic pomegrenate lib. (thanks btw for writing the > dep-resolver, I didn't think it would be this simple to do the dependency > loading). > > > > I'm not sure how the conflict resolution works but you should be able to use > any cljs version you want. The only things written in stone are the deps of > the shadow-cljs uberjar, can't change the clojure version after the fact. > > > > See: > > https://github.com/thheller/shadow-devtools/blob/master/npm-package/project.clj > > > > > > > > > > 3. Thinking back on Jiyin's question about using cljs in webpack—have you > > put any thought into the possibility of this workflow as a webpack loader? > > Maybe that's a next step? > > > > Don't need a loader. It could be a plugin that just calls "shadow-cljs --once" > > before proceeding with the rest of the JS compilation. > > > > I actually started by writing a plugin but to be honest I do not think it is > super useful. You can achieve the same via npm scripts & co. You'll need the > CLI tool for more advanced tasks (eg. REPL) anyways. > > > > I want this to be generally useful, not just webpack. No specific webpack > configuration is needed, you just somehow need to compile before calling > webpack. "webpack -w" and "shadow-cljs --dev" side-by-side actually just > works. > > > > > Awesome job turning this webpack discussion into a real tool we can > > explore! 🎉 > > > > Thanks. > > > > One issue that needs to be addressed is the widespread use of CLJSJS packages > in popular libs like reagent&co. Can't have cljsjs.react react.js if you are > supposed to use npm react. > > > > I can easily skip over all foreign-libs but then (:require [cljsjs.react]) > wouldn't have the effect of ensuring that "React" is available on global. > Not yet sure how to best handle that yet. > > > > Still have a few ideas I want to explore, haven't totally given up on the > Closure Compiler yet but it making life harder than it should be. > > > > -- > > Note that posts from new members are moderated - please be patient with your > first post. > > --- > > You received this message because you are subscribed to a topic in the Google > Groups "ClojureScript" group. > > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/AGXku7Ous0Y/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > clojurescrip...@googlegroups.com. > > To post to this group, send email to clojur...@googlegroups.com. > > Visit this group at https://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
