ClojureScript

REPL support for libs compiler opts

Details

  • Type: Enhancement Enhancement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Completed
  • Affects Version/s: 0.0-3308
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

Today, module processing and the lib dependency index setup occurs only when cljs.closure/build is invoked. This ticket asks for the same setup to occur if either :libs or :foreign-libs options are passed when a REPL is launched (without an explicit build step occurring first, as is done in the Quick Start examples involving cljs.repl/repl).

An example:

(cljs.repl/repl (cljs.repl.node/repl-env)
  :foreign-libs [{:file "libs/greeting.js"
                  :provides ["greeting"]
                  :module-type :commonjs}
                 {:file "libs/german.js"
                  :provides ["german"]
                  :module-type :commonjs}])

The above would be sufficient to cause, for example, CommonJS module processing to occur, and the results to be available within the REPL.

Additionally, the implementation should defer processing to after REPL -setup has been called, in case the REPL establishes an :output-dir for :merge-opts during -setup, thereby ensuring that any module processing output goes to the correct :output-dir.

Activity

Hide
Mike Fikes added a comment -

The attached CLJS-1313-v1.patch is working fine for Ambly, but it fails for the Node REPL. Interestingly, Maria Neise was finding that CommonJS processing was not quite working properly under Node, even with an explicit build step, when compared to Nashorn. Apart from general discussion that could be had about suitability of such a patch, there is a specific concern with Node that needs to be sorted.

Show
Mike Fikes added a comment - The attached CLJS-1313-v1.patch is working fine for Ambly, but it fails for the Node REPL. Interestingly, Maria Neise was finding that CommonJS processing was not quite working properly under Node, even with an explicit build step, when compared to Nashorn. Apart from general discussion that could be had about suitability of such a patch, there is a specific concern with Node that needs to be sorted.
Hide
Mike Fikes added a comment - - edited

So, with further investigation, it looks like the issue with using this patch with Node is actually a separate problem with Node: CLJS-1314

Additionally, I can confirm that the patch functions properly for Nashorn.

Show
Mike Fikes added a comment - - edited So, with further investigation, it looks like the issue with using this patch with Node is actually a separate problem with Node: CLJS-1314 Additionally, I can confirm that the patch functions properly for Nashorn.
Hide
David Nolen added a comment -

Does this patch still apply to master?

Show
David Nolen added a comment - Does this patch still apply to master?
Hide
Mike Fikes added a comment -

I took a look and there might be a regression that we need to sort first (see CLJS-1314).

Show
Mike Fikes added a comment - I took a look and there might be a regression that we need to sort first (see CLJS-1314).
Hide
David Nolen added a comment -

Is this patch up-to-date?

Show
David Nolen added a comment - Is this patch up-to-date?
Hide
Mike Fikes added a comment -

Yes, David. I applied the patch to master and tested it with the slight revision that Maria suggested to the greetings.js in CLJS-1314 and it worked perfectly in the Node REPL, the Nashorn REPL, and also in the Ambly REPL (thus addressing the possibility that REPLs might use :output-dir. It also still passes unit tests.

Show
Mike Fikes added a comment - Yes, David. I applied the patch to master and tested it with the slight revision that Maria suggested to the greetings.js in CLJS-1314 and it worked perfectly in the Node REPL, the Nashorn REPL, and also in the Ambly REPL (thus addressing the possibility that REPLs might use :output-dir. It also still passes unit tests.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: