I have created a basic re-frame app using the template lein new re-frame my-proj. This particular project is interfacing with a framework (ecsy) that requires some ES6 modules and ES6 classes e.g code that is generated by the user, not simply called from cljs. Since Clojurescript does not currently generate ES6 code, I have created some wrapper ES6 modules in my project from which I plan to call into cljs code.
After much futzing, I have discovered that it's not necessary to turn these js wrapper modules into full-blown npm modules under 'node_modules', but rather I can simply put them in a sub-directory of my project e.g resources/libs and then add this directory to :js-options in shadow-cljs.edn:
{:lein true
:nrepl {:port 8777}
:builds {:app {:target :browser
:output-dir "resources/public/js/compiled"
:asset-path "/js/compiled"
:modules {:app {:init-fn re-pure-ecs-simple.core/init
:preloads [devtools.preload]}}
:devtools {:http-root "resources/public"
:http-port 8280}
;;add this
:js-options {:js-package-dirs ["node_modules" "resources/libs"]}}}}
So everything works fine now, but the only problem is if I edit any of the js files in 'resources/public' the lein.bat dev compiler doesn't detect the changes. I can go in and make a mock change to a '.cljs' file, which does cause the compiler to re-compile, but it still doesn't pick up on the changes made to the '.js' file (or '.mjs' file). I have to kill, via ctrl-c, the compiler and re-start it to get the change propagated. Unfortunately, this takes about 15 seconds to compile since it's a full compile.
I tried adding 'resources/libs' to my 'project.clj':
:source-paths ["src/clj" "src/cljs" "resources/libs"]
to no avail.
I also tried deleting the compiled js files from <my_proj-dir>/resources/public/js/compiled/cljs-runtime:
rm 'module$node_modules$systems.js' 'module$node_modules$systems.js.map'
In this case, the compiler does re-generate the files (upon doing a mock .cljs change), but it still uses the prior version e.g. it must be using a cached version.
Is there a way I can add a watcher to this js directory so I can do incremental builds? There's obviously a watcher on the 'src/cljs' directory already. I have consulted the shadow-cljs user gd. but honestly, it's a little overwhelming.
You can follow the directions for requiring local .js in the User's Guide.
Basically you put the .js files into the same folder as your .cljs file and then just require it via (:require ["./foo.js" :as foo]). No additional config required.
Related
I'm using the GCE library in Go, along with go modules.
I'm finding that, while it happily compiles and runs unit tests, it's not resolving those types (e.g. compute.Instance) in the Goland IDE. I'm using 2020.2.
I first added this dependency by hand-coding (adding "google.golang.org/api/compute/v1" to my imports, and letting the module handler load whatever it needs). It added google.golang.org/api v0.50.0 to my go.mod file.
I've tried the old "Invalidate and Restart" approach, and it didn't do anything. I have another project where a different version of that module happens to be loaded, and it works fine on that one.
I've even tried a more nuclear version (Invalidate (no restart), close project, close IDE, delete the .idea directory, and delete the contents of ~/.cache/JetBrains). Still no dice.
FWIW my go module's version is go 1.15
You can navigate to the package sources by pressing Command/CTRL+Click on the import statement (or via External Libraries menu in Project View) and find compute-gen.go file and size limit warning. The IDE behaves as expected.
As a workaround, you can invoke Help | Edit Custom Properties... and add the following line idea.max.intellisense.filesize=8500000 (depends on the original file size), restart GoLand. Please, keep in mind that the IDE can be slow when dealing with large files even if they are not open in the editor.
You can read more about the idea.properties file here.
I am trying to move away from WebStorm and trying to configure VS Code to get few functionalities of WebStorm. I am trying to implement File Watcher functionality in VS Code.
I used to have File Watchers for Jade and Stylus in WebStorm. I already have gulp tasks for them and have added them in tasks.json as well. I have even provided keybindings for them too. But I have to run them manually. What I want is, whenever a file is saved, it checks whether it is a Jade file or a Stylus file and then run the appropriate task to generate either HTML or CSS file.
Is it possible to do it in VS Code yet? If yes, then how can I do that?
You must create an extension to accomplish your scenario. You said you already have gulp and task.json with your automation, so I think it would be relatively easy to translate that to an extension.
You should take care with this points when creating your extension
package.json
You extension should work for Jade or Stylus, so the package.json file should have:
"activationEvents": [
"onLanguage:Jade",
"onLanguage:Stylus"
]
OnSave Event
There are two events that you could use to detect file saving: onDidSaveTextDocument or onWillSaveTextDocument, depending on your needs.
FileWatcher
VSCode has a built in FileWatcher, you just have to create it via vscode.workspace.createFileSystemWatcher. The point is that it just monitors files within the opened folder/project.
If you need to detect changes outside, you should use fs.watchFile or chokidar.
Publishing/Installing
Don't worry if you think your extension only works for you or you can't publish on marketplace, for any reason, because you can create your own extensions, package them and install locally.
I'm trying to figure out if it is worthwhile moving to webpack, I am leaning towards saying no - figuring I have more important stuff to do - but I would like to see some practical examples of how to make webpack work.
So if I have the following Gulp.js task how would I do them as a webpack task?
gulp.task('subpaths', ['clean_subpaths'],function() {
//Minify and copy all JavaScript (except vendor scripts)
gulp.src(paths.subpath_scripts)
.pipe(fileinclude({
prefix: '##',
basepath: '#file'
}))
.pipe(contextswitch())
.pipe(uglify())
.pipe(strip())
.pipe(rename(function (path) {
path.basename += timestamp;
}))
.pipe(gulp.dest('public/longcache/javascripts/subpath'));
});
So the tasks above do -
include files inside of other files for processing.
run the piped content through my own defined code - I guess in webpack
that would be run my own plugin?
uglify
remove console statements
rename the output file so it has a version.
write out to a specific location
The first item -- include files inside of other files -- is one of webpack's biggest benefits, speaking as someone coming from an all grunt/gulp workflow. Instead of managing dependencies externally (in your build tools), and having to ensure that files are combined correctly based on their runtime dependencies, with webpack your dependencies are part of the codebase, as require() expressions. You write your app as a collection of js modules and each module loads the modules it relies on; webpack understands those dependencies and bundles accordingly. If you're not already writing your js in a modular fashion, it's a big shift, but worth the effort. This is also a reflection of what webpack is meant for -- it's conceptually oriented around building a js application, not bundling some js that your site uses.
Your second item would more likely be a custom loader, which is easier to write than a custom plugin. Webpack is very extendable, throughout, but writing custom integrations is poorly documented.
Webpack's Uglify plugin will also remove console.logs, super easy.
Specifying output details is part of your basic webpack config, just a couple of options to fill in.
It seems that you have to manually checkout a bunch of repos, and when I tried to run the core-tests runner.html, they reference htmls from outside the folder which is restricted by the browser
Polymer uses a notion of components. We define a component as a set of shareable resources in a folder. All of your components should be together in one master folder (I usually call it components). This way one component can reference another component by looking in ../<component-name>/.
A project will generally look something like this:
my-project/
index.html
components/ <-- could be symlink or a server redirection
platform/ <-- polyfills
polymer/ <-- polymer
core-ajax/ <-- a custom element
...
core-tests in particular, is itself a component. It lives in the components folder and runs tests on other components (by looking at ../<component-name>/ as above).
So, if your web-root in the example above is my-project, you should be able to access my-project/components/core-tests/runner.html to run those component tests.
There are multiple ways to populate the components folder. The easiest way is to use Bower (http://bower.io) with a command like bower install Polymer/core-elements.
You can also use Git checkouts, or ZIP archives. There is a nifty utility for downloading Bower packages as zip files at bowerarchiver.appspot.com. E.g.:
http://bowerarchiver.appspot.com/archive?core-elements=Polymer/core-elements
Will get you a zip of the core-elements Polymer component, with all of it's dependencies.
There are two Yeoman generators that can help you with starting off: yo polymer and yo element
yo polymer is based on the polymer seed-element and yo element is based on the polymer-boilerplate.
I ended up writing a blog post on getting the hang of these different setups. If you get the latest version of the generator from the github repo it will scaffold an app for you:
npm install -g git+https://github.com/yeoman/generator-polymer.git
Also make sure to have a look at the vulcanize task to concat your components.
I'm trying to compile some JS libraries that we have with lein-cljsbuild to integrate them in our ClojureScript code base. First I added some goog.provide in top of each file, and the files are hierarchically organised in a directory tree according to their namespace (like in Java). That is namespace a.b.c is in src-js/libs/a/b/c.js
I have put the JS files in the root directory of the projects in src-js/libs, and I have the following :compiler options for lein-cljsbuild:
{:id "prod",
:source-paths ["src-cljs" "src-js"]
:compiler
{:pretty-print false,
:libs ["libs/"]
:output-to "resources/public/js/compiled-app.js",
:optimizations :simple}}
None of the JS files get compiled into the compiled-app file. What's wrong?
I also tried to put them in resources/closure-js/libs without success.
I'm using lein-cljsbuild 0.3.0.
First, unlike what is suggested in some texts, you do not need to include your private closure library locations in any classpath configuration statement in your project.clj. So unless the "src/js" directory included in your "source-paths:" statement is for some other purpose, you can remove it.
Second, the only thing to add to your project.clj, for the sake of bringing in your private closure code, is the "libs:" reference you have made; BUT unlike what you have entered, that reference must be to a specific *.js file (or files) and not merely a directory. So if the library you want to used is in a file named test.js and that resides in the /src/js directory, your libs: entry would be: "src/js/test.js". See the cljs-build release notes if you want to use that plugin's default :libs directory option.
Third, (and it looks like you know this already, but this is what tripped me up) if you are using a browser-backed REPL (repl-listen option of cljsbuild), you still will not be able to load/reference/use your private library assets from that REPL until you include a :require statement somewhere in the source for your compiled-app.js (e.g. "(ns testing (:require [myprivatelib]))" ), THEN you must re-compile (lein cljsbuild once) and reload your browser page with a link to compiled-app.js. This brings in that code base. Otherwise, your browser REPL will just keep insisting that the namespace provided in your closure library is not defined.
I hope this helps.