> Where is the difference in putting code into node_modules or compiled then using webpack?
I'm not sure either. But here's what I see: * in `node_modules/` there are always tens or even thousands of folders, which I'm never happy to open it. * for hot module replacement issues, sometimes we want to ignore the whole `node_modules/` because of the amount of the files, https://webpack.js.org/configuration/watch/#watchoptions-ignored . I don't think all of us will ignore that folder, but we might do and we consider code in `node_modules/` remaining the same. As a result, using `resolve.alias` appears more acceptable to me. On Wed, May 17, 2017 at 2:12 PM Thomas Heller <th.hel...@gmail.com> wrote: > On Wednesday, May 17, 2017 at 3:51:14 AM UTC+2, Jiyin Yiyong wrote: > > I don't like the way of writing `x.assoc(null, 'foo', 'bar')` by myself. > Also I don't people would accept that. > > > > > I wouldn't as well, but that was an example to show that you can use CLJS > code directly without modifying it in any way. > > import { assoc } from "shadow-cljs/cljs.core"; > assoc(null, "foo", "bar"); > > also works. assoc is an ugly example because of the leading null but it is > the shortest form to replace the CLJS {} empty map literal. {} would mean > empty JS object which doesn't work with assoc. > > > I see the problem now. ClojureScript compilers may have tricky behaviors > that make it different from CoffeeScript's compiling processes. > > > > The compiler is pretty straightforward actually, the tricky parts are the > version conflicts. If there was a way to ensure that everything always used > the exact some compiler configuration/version this would be possible, but > there is not AFAICT. > > > Putting `x.cljs` files in npm is fine, it's just slower. To me compiling > ClojureScript is always slower, I already accepted that. > > > > [:script] Build completed. (23 files, 1 compiled, 0 warnings, 0.12s) > > I think 0.12s is pretty fast. That is running in --dev mode recompiling > one changed file with hot-reload enabled. > > Of course it is slower if you always run "shadow-cljs --once" which > includes starting the JVM each time. "shadow-cljs --dev" will be > substantially faster when re-compiling. > > > > > > > I think here are may main concerns: > > > > > > * in js projects, we regard code in `node_modules` are modules instead > of source code. For web projects using Webpack, I would prefer using a > 'compiled/' folder to hold the code and then config `resolve.alias` to make > sure I import the code with `require('cljs/foo.bar.core')`. > https://webpack.js.org/configuration/resolve/ > > > > Not sure what you mean. Where is the difference in putting code into > node_modules or compiled then using webpack? The behavior is identical, the > node_modules version just doesn't need the resolve.alias? Both versions > require that you have your code compiled before running webpack, which > directory you load them from should be automatic? > > > > * For nodejs projects, somehow I can accept the solution that we use > `require('../../compiled/foo.bar.core')`. But I guess it may bring > problems, which makes your `shadow-cljs` solution a better choice... > > > > Yes, I hate relative paths. Actually the output folder where things end up > is a config option. So if you really wanted to have your compiled folder > that can be done. I just don't see an upside to it. > > > > > * does shadow-devtools compiled cljs files incrementally? If it does, > Webpack may use it to hot replace module. > > > > Yes, incrementally. Don't know anything about HMR but shadow-devtools > already has hot-reloading (ala figwheel) built-in. I just didn't enable it > yet because other things were more important. > > Can't tell if Webpack HMR would work since I have never used it. > > Thanks for the feedback, I hope I lessened your concerns. > > Keep it coming. > > Remember: this is evolving as we discuss it, I have no idea what JS devs > want so without feedback I'll be building what I want. That may or may not > align. > > -- > 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 > 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. > -- 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.
