After I installing jest using npm install jest and adding "test":"jest" in package.json, I expect keywords like "expect" to work automatically in my cljs test files:
(.toBeInTheDocument (expect (.getByText screen "Some Component")))
But I get that "expect" is undefined. js/expect gives undefined as well. How to get jest to work with clojurescript?
-- EDIT --
I installed lint a this library, but still can't get jest functions to work in my test file.
This is not what you asked, but I think most ClojureScript projects use tests written with clojure.test and mocking facilities of the language (eg. with-redefs), so I think it will be much easier to follow that path instead.
Check these links depending on the build tool that you use for your project:
figwheel: https://figwheel.org/docs/testing.html
shadow-cljs: https://shadow-cljs.github.io/docs/UsersGuide.html#_testing
Related
In many projects, I have a tools/tools.go file that allows me to have local versions of the tools I use (reference).
I also have go:generate statements in my code to automate the generation of mock files using https://github.com/golang/mock/mockgen. I have a local version of mockgen under a bin folder of my project and I can generate all the mocks of my project by running something like PATH=./bin:${PATH} go generate ./....
Vscode-go recognizes the go:generate statements in the code and can generate code for us.
I would like to know if there is a way to get vscode-go to run mockgen (through gopls.generate) using the local version I have under the bin directory.
With the setting go.alternateTools, vscode-go lets us specify an alternate path for the tools used by the extension (i.e. dlv). I tried to configure that option for mockgen but it didn't change anything. My guess is that it does not work because vscode-go runs mockgen through gopls.generate; it does not run mockgen directly. But this is just a guess.
Below is the error I get if I don't have a mockgen binary in my $PATH:
[Info - 5:44:18 PM] 2021/08/08 17:44:18 xxxxxxx.go:19: running "mockgen": exec: "mockgen": executable file not found in $PATH
operation="generate"
Does anyone have any idea? 😅
Edit: see #Zyl's comment there for a very good alternative.
I've run into the same problem today. Found this solution, which worked for me if someone needs this in future:
export GOPATH="$HOME/go"
export PATH="$GOPATH/bin:$PATH"
And then run (in the directory where file with the "go:generate" comment is located)
go generate
Can anyone please help explain this? I am new at using Sass. But I cant understand why people use compiler for sass files when they can be run through terminal.
I actually had the same question some time ago when I was learning SASS.
I kept wondering why most tutorials involved using GRUNT / GULP or some kind of task runner when there where sass proprietary commands even for live-watching your files with a command such as:
sass --watch app/sass:public/stylesheets
I will quote myself here in the question (that no one answered) just to share my experience with SASS compiling:
Grunt: using grunt-contrib-sass - Everything has worked smoothly; I chose this one over grunt-sass for no particular reason, but I've read that the latter uses libsass(c++) which is faster than the traditional ruby Sass.
Gulp: using gulp:sass - I often encounter an error when watching
files, it doesn´t find some partials, but if you save again,
everything is fine (this is addressed in their common issues -this
solution hasn't worked for me though), also it doesn't generate sass
maps as a default you have to use gulp-sourcemaps on top.
Straight from Console: no task runners - Works fine so far, generates
sourcemaps, and lets you know where there's an error, just like with
Grunt and Gulp.
So after working on different projects using SASS I'd say the reasons are:
Tutorials popularized the use of task runners when using SASS in its early times
In a project, you rarely use SASS just by itself, you most likely want to run other tasks, so it makes sense to add your SASS task to the flow, which saves time and makes sense.
It's easier to run a simple command such as gulp sass or just gulp to run the default gulp task (that should include the sass task) than to remember a long command in which you have to put the paths over and over again.
After a while I realized that you can use NPM scripts in your package.json to run the SASS command line tools like so:
"scripts": {
"sass": "sass --watch app/sass:public/stylesheets --style compressed"
},
And then run it from the command line: npm run sass
the above requires no configuration and you don't have to remember the whole command by heart.
To conclude, there is nothing wrong in using the CMD SASS without other compilers/task runners, just use whatever you feel most comfortable with.
I'm trying to setup a build flow in a Visual Studio environment (13, on Windows 7) using browserify, and I am getting some strange behaviour trying to get browserify to work. I'm new to the environment as well as the technology, so I'm fairly confused here.
For the purposes of this test, my file structure is the same as the Basic API example found here: http://viget.com/extend/gulp-browserify-starter-faq I installed browserify using npm. It is running version 5.12.0
If I place app.js and hideElement.js in a simple directory, such as C:\Temp, and run
c:\Temp> browserify app.js
everything works fine. It bundles up all three of the required files, and spits them out. But if I run the browserify command from my project directory (C:\Users\\documents\visual studio 2013\Projects\ExcelConverter\ExcelConverterWeb), the following error spits out at me:
C:\Users\<name.redacted>\Documents\Visual Studio 2013\Projects\ExcelConverter\ExcelConverterWeb>browserify app.js
Error: SyntaxError: Unexpected token ? while parsing json file package.json
at fns(C:\Users\<name.redacted>\AppData\Roaming\npm\node_modules\browserify\node_modules\module-deps\index.js:402:30)
at fs.js:271:14
at Object.oncomplete (fs.js:107:15)
I've looked at the file in question, and I can't make heads or tails of it. So, what's going on here? How come browserify runs fine when I execute it from one directory, but not from the other? I appear to be using the same executable.
(I'm trying to use browserify as part of a gulp-based build process, but seeing as the errors produced by gulp are basically the same as those I see when I run from the command line)
I have run into "Unexpected token ?" problem. Changing package.json encoding type to 'ANSI' helped solving it. Most of the text editors have that option when "Save As" change Encoding option, then hit "Save"
See if that work for you.
Recently, while getting acquainted with the Mocha javascript testing framework, I came across this section that I didn't understand:
Makefiles
Be kind and don't make developers hunt around in your docs to figure
out how to run the tests, add a make test target to your Makefile:
test:
./node_modules/.bin/mocha --reporter list
.PHONY: test
Which is hardly descriptive, and not very helpful if you don't know what a makefile is.
So, What is a Makefile? And how is it different from a Gruntfile or using npm run?
Makefile
A Makefile (usually with no file extension) is a configuration file used by the Unix make tool.
Quoted from one of the best introductions I have found on Make that I highly recommend you read if you are interested in knowing more about make specifically, and task-runners in general.
Make is the original UNIX build tool. It existed a long time before
gulp, or grunt. Loved by some, loathed by others it is at least worth
being aware of how make works, what the strengths are and where it
falls short.
Make is available on UNIX-like systems. That means OSX, BSD and Linux.
It exposes any system command meaning that you can run system commands
and execute arbitrary scripts. There is no doubt that tools like gulp
and grunt are inpsired by or at least a reaction to make.
To use make you create a Makefile and then run make [what to run] from
the terminal.
Gruntfile.js
A Gruntfile.js is a javascript configuration file used by the Grunt.js tool.
The newer node.js version of make, if you will, is Grunt.js which is cross-platform (works on Windows) and written in Javascript. Both can do similar things like concatenate files, minify css, run tests, etc. and there is a lot of information on the web about Grunt.
'npm run'
Another option that some developers prefer to use is npm itself, using the npm run command as described in this informative post on how to use npm run for running tasks:
There are some fancy tools [Grunt] for doing build automation on javascript
projects that I've never felt the appeal of because the lesser-known
npm run command has been perfectly adequate for everything I've needed
to do while maintaining a very tiny configuration footprint.
If you haven't seen it before, npm looks at a field called scripts in
the package.json of a project in order to make things like npm test
from the scripts.test field and npm start from the scripts.start field
work.
npm test and npm start are just shortcuts for npm run test and npm run
start and you can use npm run to run whichever entries in the scripts
field you want!
Other good introductory resources:
Introduction to grunt.js and npm scripts, and choosing between the
two.
Cross platform JavaScript.
Package Managers: An Introductory Guide For The Uninitiated Front-End
Developer.
I am having a hard time finding code validation solutions for emacs, something/s to check that my javascript / css / ruby etc is valid code, where is all this stuff at?
I assume that you're referring to basic syntactic correctness, in which case you should look at flymake, which is included with Emacs, and which runs a validation program in the background, parses its output, and marks up the buffer with errors and warnings.
And, to get you started, here is a small module for using flymake with Ruby, and a similar one for flymake with javascript using jslint as the validation program.
that's why you test ruby mate. Even js has test suites now too.
As for the css, you can always use things like autopair, or textmate.el to ensure you close your hashes, and maybe even add the semi-colon to your css as well (I should see if that exists actually, thanks).
for js - there is an emacs wiki page but it seems to be quite out of date: http://emacswiki.org/emacs/FlymakeJavaScript
Here's what I did instead. First I installed jslint on node.js
sudo apt-get install nodejs npm
npm install jslint
ln -s ~/.npm/jslint/0.1.8/package/bin/jslint.js ~/.local/bin/
For emacs integration I then tried installing the package flymake-jslint in emacs (I'm using emacs24 with included package manager) and pointing it at jslint but it just wouldn't work.
I then followed the instructions here http://www.thoughtspark.org/node/59 - I created a bash wrapper script for jslint.js and pointed the .el snippet at it and it works fine.