This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (7)
- # beginners (83)
- # boot (26)
- # cider (38)
- # cljs-dev (90)
- # cljsrn (14)
- # clojure (83)
- # clojure-dev (12)
- # clojure-france (2)
- # clojure-greece (4)
- # clojure-italy (12)
- # clojure-russia (81)
- # clojure-shanghai (1)
- # clojure-spec (39)
- # clojure-uk (28)
- # clojurescript (159)
- # consulting (1)
- # cursive (16)
- # data-science (6)
- # datomic (14)
- # devops (3)
- # emacs (22)
- # figwheel (1)
- # graphql (14)
- # hoplon (3)
- # jobs (1)
- # jobs-discuss (7)
- # leiningen (1)
- # luminus (6)
- # lumo (1)
- # off-topic (8)
- # om (6)
- # onyx (38)
- # pedestal (30)
- # perun (3)
- # re-frame (31)
- # reagent (9)
- # ring-swagger (2)
- # rum (2)
- # sql (2)
- # unrepl (15)
- # untangled (1)
does someone know where the code is that decides that
(ns my.app (:require [goog.something :as x])) (x/foo) does not emit the
goog.something.foo.cljs$core$IFn$_invoke$arity$1 ? ... version but goes directly to
goog.something.foo(...)? Is that just tied to
goog is hard coded, created issue here https://dev.clojure.org/jira/browse/CLJS-2040
looking for feedback from folks writing
node apps about a new feature I'm working on, see https://github.com/thheller/shadow-cljs/issues/10
do you think this would be an improvement to the current
js/require situation or is this not a problem at all?
I’ve been thinking that how we should support it in
:npm-deps in the CLJS compiler proper
@anmonteiro yeah I figured you were working on something similar, thats why I started writing things down :slightly_smiling_face:
(:import [npm$react-native Text View]) or some other character that doesn't break the reader
Well, the naming is something to think about but probably
npm. prefix would be just fine
@anmonteiro Doesn't module processing already allow using
:require with the name used in
node-inputs expands foreign-libs entries so that instead of directories it contains list all the JS files from npm modules?
wouldn't that generate
:provides ["react-dom"] for react-dom npm package index file, and
:provides ["react-dom.server"] for server.js file in react-dom package?
I tested something like that at least, not sure what the current implementation is
Right, if I read this correctly
provides is only added to main files: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/module_deps.js
Should be easy to generate
provides for any files by relativizing the path against
:roots or what ever the package.json option is and replacing
Without prefix there is greater chance the there will be name clashes, but I guess
:provides values could be prefixed if wanted
How does the
:npm-deps stuff handle the duplication of npm packages? does it dedupe or just include the code twice?
@thheller npm may not be around in few years, yarn or something else could replace it, I would suggest more general mechanism of requiring “foreign” code via native package system - we have
:require-macros we could have new
:require-foreign or something like that, without introducing artificial namespaces aka magic
I personally would vote for something like this
(:require-native [react-dom.server :as rdom :via npm]), where
:via would be optional, by default the compiler would try to figure out which native package system to use
I think we should then stick to what
require does and not try to translate the string to a symbol
@juhoteperi I want to get rid of
:foreign-libs if possible so not a fan of that idea
Users shouldn't not be required to write it, but I find it works well with
:npm-deps as API between npm integration and Cljs compiler
(:js/require ["../../foo" :as foo]) so it mirrors the
js/require form just like
:require has a
@juhoteperi yeah I'm still not a fan of
:npm-deps either, much rather leave that to
isn't npm packaging the maven of js? will there really ever be anything else? (Not talking about the tool, talking about package.json, the npm repository layout, etc) @darwin
I don’t use “maven” anywhere in my code, so I don’t really want to mention “npm” there, that is just underlying impl detail, IMO
@thheller there’s a lot of stuff we don’t handle - enhancements will be made based on feedback on actual
@dnolen I didn't like
:npm-deps to begin with so I'm obviously exploring alternatives ...
@thheller yes I know - but I’m not really concerned about that :slightly_smiling_face:
not expecting you to be ... but I think you were too fast to accept
:npm-deps and when I can show something better I hope you'll reconsider. that is if I actually find something better. :wink:
Some feedback: I was working on Reason and BuckleScript a while ago and they have their own
bsconfig.json file. This means you have to add the dependency twice. No good, hopefully Cljs will be able to avoid that.
There are well documented flaws with the default npm client: https://code.facebook.com/posts/1840075619545360
Given that open extension is also a core value of clojure it is also odd to tie this feature to a concrete implementation (npm) with no way of changing it.
Right, I don't plan on using it. The line of reasoning is that it isn't useful and is a waste of resources in dev time.
@dnolen you might still want to use a library that is using it though. so you may be exposed to it whether you want to or not.
just like "everything" requires
cljsjs.react now and people sometimes have to work around that
case in point https://github.com/cljsjs/packages/tree/master/material-ui with the
:exclusions. that is not user friendly and just gets worse the more foreign packages you use.
or where you have to create empty
(ns cljsjs.react) files if
React is not provided by
@dvingo if you can point at some kind of survey that shows a mass exodus off NPM as dependency delivery mechanism I will look at it
my evidence is anecdotal, from blog posts and repos I use, I understand that was a non-evidence based statement.
@thheller if people want to use complex JS packages that don’t play well with Google Closure - they know what they are getting into
@dnolen that is not managing dependencies ... that is working around issues that don't need to exist in the first place.
@thheller sorry I don’t really have anything more to add, and I don’t find your positions convincing … yet
no worries ... I'm just exploring and looking for feedback. absolutely no expectations beyond that.
just deleted the
npm.react alias code based on the feedback although it was already fully implemented
@anmonteiro fwiw, I honestly don’t have a problem with supporting strings in
:require instead of just symbols
If you have
(ns foo.core) (defmacro add [a b] `(+ ~a ~b)) (defmacro funky [form] (eval form))
(funky (add 2 3)) works only if you refer both
add (leaving off
add results in the inner
eval failing to resolve
In ClojureScript, a refer for
add is insufficient.
This is more of a curiosity on my part (but perhaps it could be a corner case in that the ClojureScript compiler could inject more into
env when doing macroexpansion). Curious if there is any clear view on this corner case.
This came up in the context of this SO http://stackoverflow.com/questions/43985923/how-can-i-force-evaluation-of-nested-macros-in-clojurescript For me it is an academic interest, but it got me thinking that there might be a bug. Anyway asking mainly out of the academic interest. (It crossed into an area where my mental model is weaker than I'd like it to be.)