Clojurians
#cljs-dev
<
2017-01-29
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

bronsa11:01:40

@alexmiller i think it makes sense that that works in clojure

bronsa11:01:11

it's equivalent to (case '(:a :b) (quote (:a :b)) :works)

bronsa11:01:27

replace quote with anything else to see why that works

bronsa11:01:48

it's just matching foo to either quote or (:a :b)

anmonteiro19:01:34

@dnolen other than historical reasons, are there any hurdles to making use work just like in Clojure?

anmonteiro19:01:45

i.e. not being limited to just :only

dnolen19:01:10

Yes it's not supported in purpose

dnolen19:01:20

Not interested in adding that featire

anmonteiro19:01:06

right, but besides that. It would be feasible right?

anmonteiro19:01:27

I'm just interested in understanding if there would be any technical limitations to implementing such thing

bhauman19:01:31

@anmonteiro the filename _dirname thing hasn't been resolved I don't think

bhauman19:01:55

or at least the behavior is way off

shaunlebron19:01:18

d.nolen: would you take a PR that adds a spec for compiler options? would like to start tracking them for autodocs

anmonteiro19:01:24

@bhauman hrm, what are you seeing that seems wrong?

bhauman19:01:45

It's giving me random filenames

bhauman19:01:16

no rhyme or reason

bhauman19:01:29

file_reloading.js reports target/js/compiled/out/clojure/set.js

bhauman19:01:53

and then later "target/js/compiled/out/cljs/spec/impl/gen.js"

bhauman19:01:13

in a dynamic call

dnolen20:01:06

@shaunlebron: no not until it's clear closure.spec is settling down

bhauman20:01:25

@anmonteiro just wondering if you got my message

anmonteiro20:01:00

sorry, I read what you wrote above

bhauman20:01:14

I'm currently working around

anmonteiro20:01:33

can you tell me what steps I need to take in order to repro it?

anmonteiro20:01:37

busy now but can take a look later

bhauman20:01:53

simple repro: use earlier cljs ex. 1.9.229 create a node project with a cljs file (def loadtime-path js/filename) (defn runtime-path [] js/filename) compare the results to cljs 1.9.459

dnolen21:01:29

@bhauman we might not actually care about that particular case

dnolen21:01:42

I’m more concerned about those not being correct in JS libs

dnolen21:01:53

when you’ve already called through require

bhauman21:01:24

this is an expected env idiom though correct?

dnolen21:01:45

nothing about how we integrate with Node.js at dev time is idiomatic anyway

bhauman21:01:55

well that is true

dnolen21:01:03

Google Closure global namespace convention is in direct conflict with Node.js idioms

dnolen21:01:15

so we don’t really care about matching expectations at all

bhauman21:01:16

yes I get that

dnolen21:01:42

we should focus on not breaking deps

dnolen21:01:48

and then decide if we care about the rest

bhauman21:01:06

I'm working around it, but I have to say its tough to work with relative paths etc in node without it

bhauman21:01:10

really tough

dnolen22:01:04

@bhauman we should see if we can make require work

dnolen22:01:18

but it might turn out that we just need two modes

dnolen22:01:36

one for people who don’t actually care about CommonJS integration

dnolen22:01:39

who just want to do Node.js stuff

dnolen22:01:08

it’s distinct possibility

dnolen22:01:15

Node.js is just it’s own thing

dnolen22:01:19

no other JS environment works like it

dnolen22:01:51

to be honest I don’t really care that much

bhauman22:01:59

I'm kinda there myself

dnolen22:01:00

if you’re doing Node.js only stuff none of the new things matter much

bhauman22:01:23

but figgy is broke and I gotta fix him

dnolen22:01:42

@bhauman but I wouldn’t try to fix the problem there

dnolen22:01:01

it would be more productive to see if a different approach for node_bootstrap.js is needed

bhauman22:01:16

well my approach to fixing it isn't great

dnolen22:01:24

otherwise Figwheel is just going to break if we change this again

bhauman22:01:39

it shouldn't

dnolen22:01:46

and I can guarantee what we currently have is going to get tweaked over the next couple of weeks

bhauman22:01:01

I'm js/require with an absolute path

bhauman22:01:33

which is the solution for bootstrap probably

bhauman22:01:49

it just needs to know where it is

dnolen22:01:34

@bhauman I have an idea - trying it now

dnolen22:01:49

hrm yeah nothing obvious is working, will have to look at it later

bhauman23:01:57

each loaded module in the require.cache has a filename attached

dnolen23:01:34

but currently we’re not using require to load ClojureScript compiled stuff

anmonteiro23:01:29

@dnolen what's the story like for people who have JSX stuff and want to call cljs.build.api/node-inputs?

anmonteiro23:01:47

doesn't seem like the script can run because it can't parse the JSX file

dnolen23:01:08

there’s no automatic story because it isn’t possible

dnolen23:01:25

as far as I know no one does that anyway

dnolen23:01:27

it’s unsound

dnolen23:01:43

how can JS build tool know which files have JSX in them?

anmonteiro23:01:22

sure, makes sense. but the automatic foreign-lib entry generation can't be used in this case

dnolen23:01:29

you can of course turn on :jsx preprocessing for everything

dnolen23:01:33

and it’s pretty obvious how to do that

dnolen23:01:52

@anmonteiro it can

dnolen23:01:00

just map over those entries and edit the ones you’re looking for

anmonteiro23:01:07

hrm I'm feeling I asked the wrong question

anmonteiro23:01:15

or you didn't understand what I wanted to ask

dnolen23:01:24

I understand :slightly_smiling_face:

dnolen23:01:38

there’s no automatic way to do this

dnolen23:01:44

node-inputs returns data for a reason

anmonteiro23:01:01

right, I still think we're not in sync

anmonteiro23:01:29

the script you call with JSONStream and such

dnolen23:01:31

oh you mean if the entry point is JSX

dnolen23:01:54

yes you will need to do something else entirely

dnolen23:01:04

but that’s fine

anmonteiro23:01:15

right. deps shouldn't change that often

dnolen23:01:05

I am more concerned about the related case more people are going to want - the entry point is ClojureScript

dnolen23:01:38

probably when we think about that we might want to consider what to do about ES6/JSX/etc. entry points

anmonteiro23:01:24

what doesn't work now, given that use case?

dnolen23:01:34

it just doesn’t work

anmonteiro23:01:40

automatically figuring out what entries to put if you only require it from CLJS?

dnolen23:01:40

we don’t have any support for CommonJS requires

anmonteiro23:01:53

right, exactly

anmonteiro23:01:18

but you can still do it somehow, right?

dnolen23:01:20

this probably the highest priority enhancement to what we currently have

anmonteiro23:01:27

it's just hard

dnolen23:01:32

no, there’s no way to do it at the moment

anmonteiro23:01:20

I was thinking: 1. create some JS file which requires all those node modules 2. compute an edn file with the foreign lib entries 3. use that and don't compile the JS file with the requires

dnolen23:01:08

hrm I don’t know exactly how we’re going to do it - going to require some serious thought

dnolen23:01:41

in Closure at least one suggestion is to just load everything

dnolen23:01:51

and use dependency pruning

anmonteiro23:01:04

what I was saying was only from a specific application point of view

anmonteiro23:01:44

but there's no :provides entry in that generated thing

dnolen23:01:54

there’s really no way to make it work

dnolen23:01:01

without support from ClojureScript

dnolen23:01:36

you really want (:require [object-assign]) to know to look for the Node module

dnolen23:01:19

probably we need to index node_modules the same way we index Google Closure Library

dnolen23:01:56

@bhauman so the problem with __filename and __dirname is that these just have to be locals

dnolen23:01:13

but I can’t see how to make that work without breaking Google Closure semantics

bhauman23:01:28

yeah making a closure don't work

dnolen23:01:46

goog.provide is supposed to write to global but everything I try just doesn’t seem to work

dnolen23:01:09

but in theory it should - and maybe I’m just missing something

bhauman23:01:28

the compiler could support it by aliasing

dnolen23:01:06

prior to this release we did use Node.js require for everything except goog/base.js and foreign libs

dnolen23:01:29

it seemed to work OK, but CommonJS compiled libs just didn’t seem to work with that approach