Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shadow-cljs.edn Does not work #38

Closed
tjscollins opened this issue Jun 6, 2017 · 5 comments
Closed

shadow-cljs.edn Does not work #38

tjscollins opened this issue Jun 6, 2017 · 5 comments

Comments

@tjscollins
Copy link

Trying to run $ shadow-cljs --once fails if shadow-cljs.edn exists. Even if using the default config from node_modules/shadow-cljs/bin/default-config.edn, the same error is produced:

$ shadow-cljs --once
shadow-cljs - using package.json 1.0.20170601
shadow-cljs - loading dependencies
shadow-cljs - starting
Exception in thread "main" clojure.lang.ExceptionInfo: invalid config {:clojure.spec.alpha/problems [{:path [], :pred clojure.core/vector?, :val {:source-paths ["src"], :dependencies [], :builds {}}, :via [:shadow.cljs.devtools.config/config], :in []}], :clojure.spec.alpha/spec :shadow.cljs.devtools.config/config, :clojure.spec.alpha/value {:source-paths ["src"], :dependencies [], :builds {}}}
	at clojure.core$ex_info.invokeStatic(core.clj:4725)
	at clojure.core$ex_info.invoke(core.clj:4725)
	at shadow.cljs.devtools.config$load_cljs_edn_BANG_.invokeStatic(config.clj:41)
	at shadow.cljs.devtools.config$load_cljs_edn_BANG_.invoke(config.clj:37)
	at shadow.cljs.devtools.config$get_build.invokeStatic(config.clj:47)
	at shadow.cljs.devtools.config$get_build.invoke(config.clj:45)
	at shadow.cljs.devtools.cli$load_npm_config.invokeStatic(cli.clj:69)
	at shadow.cljs.devtools.cli$load_npm_config.invoke(cli.clj:64)
	at shadow.cljs.devtools.cli$main.invokeStatic(cli.clj:124)
	at shadow.cljs.devtools.cli$main.doInvoke(cli.clj:100)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.core$apply.invokeStatic(core.clj:657)
	at clojure.core$apply.invoke(core.clj:652)
	at shadow.cljs.cli$_main.invokeStatic(cli.clj:77)
	at shadow.cljs.cli$_main.doInvoke(cli.clj:34)
	at clojure.lang.RestFn.applyTo(RestFn.java:139)
	at shadow.cljs.cli.main(Unknown Source)

The spec seems to be expecting a vector and not a map from shadow-cljs.edn. I'm assuming this is not the intended behavior.

@tiye
Copy link
Collaborator

tiye commented Jun 6, 2017

please paste you config, and which version of shadow-cljs do you use?

There was a breaking change, you should notice: https://github.com/thheller/shadow-cljs/blob/master/CHANGELOG.md#1020170602

[BREAKING] a shadow-cljs.edn config file is now mandatory, the script can create on for you. It is now also expected to contain a map and supports :builds, :dependencies, :source-paths and probaly more in the future. If you had a vector before just wrap it in {:builds the-vector}.

Upgrade please.

npm i -g shadow-cljs

@tjscollins
Copy link
Author

Upgrading the global install fixed it. I had a local install that was upgraded to 0.9.4, but global was out of date. Thanks.

@tiye
Copy link
Collaborator

tiye commented Jun 6, 2017

I always feel confused when clojure.spec throws error messages at me. 😆

@thheller
Copy link
Owner

thheller commented Jun 6, 2017

spec errors need to improve thats for sure.

I don't like that the local install can have a different version than the global. The global should be able to just launch the local if it exists. How do other JS packages deal with this issue? I see that some packages ship a thing-cli package (ie. ember-cli, vue-cli, ...) in addition to the normal packages.

Technically you only need either the global or the local, but having the local protects the node_modules/shadow-cljs folder from getting deleted by yarn.

Still need to figure out how things are done properly in the JS world. CLJS/JVM is so different.

@tiye
Copy link
Collaborator

tiye commented Jun 6, 2017

gulp-cli is such an example, which requires gulp-cli at global meanwhile gulp installed at local. https://stackoverflow.com/a/35573218/883571

I think using commands at local is better because we often have to accept that different projects using different versions of same module. So I don't have to upgrade all my code when upstreams update.

Besides, by maintaining them at local, I can just type yarn outdated to figure out and just yarn upgrade shadow-cljs to update in current repo. It's quite handy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants