This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-17
Channels
- # aws (16)
- # beginners (82)
- # boot (29)
- # cider (43)
- # cljs-dev (90)
- # cljsrn (14)
- # clojure (79)
- # clojure-dev (12)
- # 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 (18)
- # devops (3)
- # emacs (22)
- # figwheel (1)
- # graphql (15)
- # hoplon (3)
- # jobs (1)
- # jobs-discuss (8)
- # leiningen (1)
- # luminus (6)
- # lumo (1)
- # off-topic (18)
- # om (6)
- # onyx (38)
- # pedestal (30)
- # perun (3)
- # re-frame (38)
- # reagent (8)
- # ring-swagger (2)
- # rum (2)
- # sql (2)
- # unrepl (14)
- # untangled (1)
- # vim (8)
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
?
as assumed 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?
@thheller do you have any proposal for require('react-dom/server')
style things?
right
I’ve been thinking that how we should support it in :npm-deps
in the CLJS compiler proper
What is someone has namespace starting with npm.
?
@anmonteiro yeah I figured you were working on something similar, thats why I started writing things down 🙂
“working” is not really the word yet
@juhoteperi its a special reserved alias, it would complain
(: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 :foreing-libs
entry?
yes, but it doesn’t know about slashes yet
and node-inputs
expands foreign-libs entries so that instead of directories it contains list all the JS files from npm modules?
based on what you require
it doesn’t expand blindly, it calculates the dependency graph
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
I don’t think it currently does that
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 /
with .
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?
or this fancy behavior https://docs.npmjs.com/how-npm-works/npm3-nondet
@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-native
or :require-foreign
or something like that, without introducing artificial namespaces aka magic
darwin: all for this, we should avoid hardcoding names
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
What about just using :foreign-libs
to map from a name to a file?
@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
maybe (:js/require ["../../foo" :as foo])
so it mirrors the js/require
form just like :require
has a require
mirror?
@juhoteperi yeah I'm still not a fan of :npm-deps
either, much rather leave that to yarn
or npm
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 :npm-deps
usage
@dnolen I didn't like :npm-deps
to begin with so I'm obviously exploring alternatives ...
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. 😉
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 :foreign-libs
@danvingo 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 foo/core.clj
:
(ns foo.core)
(defmacro add [a b] `(+ ~a ~b))
(defmacro funky [form] (eval form))
In Clojure (funky (add 2 3))
works only if you refer both funky
and add
(leaving off add
results in the inner eval
failing to resolve add
).
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.)