|require refer do not give errors||Timothy Pratley||12/30/13 10:31 PM|
;; not an error, but typomina does not exist
;; not an error, but listen! does not exist and will result in a runtime error:
WARNING: Use of undeclared Var
;; Warning but not an error
For the compiled output, do you generally .gitignore those files or source control them (the diffs dominate changesets)?
Are there any good ways to know when a page can be refreshed other than watching a lein cljsbuild auto terminal?
Might it be useful for a cljsbuild failure to compile to remove the target file to avoid not realizing the compilation failed?
|Re: [ClojureScript] require refer do not give errors||David Nolen||12/30/13 10:38 PM|
On Tue, Dec 31, 2013 at 1:31 AM, Timothy Pratley <timothy...@gmail.com> wrote:
A ticket exists for this. Patch welcome :)
Not sure what difference it makes, warnings are errors but without blowing up the compilation process so you can get many warnings at once.
Bad form. / is only for namespaces.
I would ignore.
Tooling questions outside of CLJS itself.
|Re: require refer do not give errors||Jonas Enlund||12/30/13 11:23 PM|
On Tuesday, December 31, 2013 8:31:40 AM UTC+2, Timothy Pratley wrote:
|Re: [ClojureScript] require refer do not give errors||Timothy Pratley||12/31/13 12:03 AM|
Is this the ticket?
It speaks of analyzer.clj, but I don't see such a file.
I do see analyze as a function in compiler.clj which sounds promising.
(map #(let [f (ns->cp %)] (hash-map :relative-path f :uri (io/resource f))))
(remove #(nil? (:uri %)))
Looks to be ignoring missing files. I suspect though that it merges with js dependencies later, and that the trick will be recognizing requires that are in neither... I'll dig into it tomorrow and see what I can discover.
Some compilers report multiple errors, it may be reasonable to classify the output however you like. My opinion is that an error is appropriate when you know 'it' just wont work, and refuse to produce an output... whereas a warning is appropriate as a hint that probably 'it' will do something you might not expect. In the specific case of an undeclared var will it always be a runtime error? I can see an argument to say some js output is better than none even if certain paths will fail.
Ah that makes sense and makes me think that the code I was looking at can't be patched so easily then.
Thanks your replies.
|Re: [ClojureScript] require refer do not give errors||David Nolen||12/31/13 5:25 AM|
On Tue, Dec 31, 2013 at 3:03 AM, Timothy Pratley <timothy...@gmail.com> wrote:
This is not the place to put this assertion check. The best location is ns form parsing in analyzer.clj.
This is already supported to some degree. Again look at analyzer.clj. Some errors will halt compilation - source reading errors, errors in the ns form, and those that would result in a mangled file. We haven't been super disciplined how we classify these. Yet another place for someone to contribute.
Verifying that random JS libs exist on disk will require more work, but there's a lot of value in starting with .cljs and .clj macro files first.
|Re: [ClojureScript] require refer do not give errors||Timothy Pratley||1/2/14 12:44 AM|
Patch is up for this:http://dev.clojure.org/jira/browse/CLJS-615
Additional details in the ticket description.
|Re: [ClojureScript] require refer do not give errors||David Nolen||1/2/14 6:33 AM|