We Keep Coding

Javascript clean architecture question: is there a way to enforce dependency restrictions on a file or directory, and write a Jest-ful test for it?

For example, let's say we have the following "clean architecture" project structure:
.
│ README.md
│ package.json
│ ...
│
└─── src
│ │ app.js
│ │ app.test.js
│ │ ...
│ │
│ └─── entities
│ │ │ foo.js
│ │ │ foo.test.js
│ │ │ bar.js
│ │ │ ...
│ │
│ └─── useCases
│ │ │ useFooAndBarToBaz.js
│ │ │ ...
│ │
...
How could a test be written to enforce the architectural concept that Entities should not have outward dependencies? IE: no file in the /entities directory should import and use any classes, functions etc found in another directory (/useCases directory in this example).
If possible, I would like to use Jest to write the test(s) (ideally in app.test.js to test the whole /entities directory, but if that's not possible then in foo.test.js to test the content of foo.js, etc etc), but I don't see anything glaringly obvious in the Jest docs about testing file imports.
There may be alternative ways to go about this (can Jest be used in combination with a bash script to walk the directories or something?), so I'm open to ideas.

Denial of Service in react-svg-loader version 3.03 due to css-what?

React solution is showing one high vulnerability in npm-audit due to Denial of Service in react-svg-loader version 3.03 due to css-what.
What is the possbile solution of the issue?
Issue is as shown below:
───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High │ Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ css-what │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=5.0.1 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ react-svg-loader │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ react-svg-loader > react-svg-core > svgo > css-select > │
│ │ css-what │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://npmjs.com/advisories/1754 │
└───────────────┴─────────────────────────────────────────────────────────────

I tried replacing react-svg-loader with https://www.npmjs.com/package/svg-react-loader. It does the same thing only we need to change the package and web pack config. It does not have any vulnerability as of now.

"Uncaught ReferenceError: require is not defined" only in some machines

I started getting this error today in the test suite of an Angular.js 1.5/Angular 5 project:
HeadlessChrome 64.0.3282 (Linux 0.0.0) ERROR
An error was thrown in afterAll
Uncaught ReferenceError: require is not defined
The issue appears after all of my tests have run successfully. What is bizarre is it runs well locally, but it's in a Jenkins CI server where it fails. From the other developers only 1 in 10 is seeing the same problem as Jenkins.
There are tons of other posts mentioning this same error but none addressed my exact problem, like this, this, this, ...
Anybody knows what the issue can be?
Edit:
The exception happens in modernizr/lib/cli.js, but no stack-trace appears:
and we get no call stack either:

After looking at the bower dependencies of our project with bower ls -o, we found a difference in a transient dependency of Zurb Foundation.
In the places were it worked, modernizr was set to 3.5.0:
├─┬ foundation#5.5.1
│ ├── fastclick#1.0.6
│ ├── jquery#2.1.4
│ ├─┬ jquery-placeholder#2.0.9
│ │ └── jquery#2.1.4
│ ├─┬ jquery.cookie#1.4.1
│ │ └── jquery#2.1.4
│ └── modernizr#3.5.0
In the places were it didn't work, it was set to 3.9.0:
├─┬ foundation#5.5.1
│ ├── fastclick#1.0.6
│ ├── jquery#2.1.4
│ ├─┬ jquery-placeholder#2.0.9
│ │ └── jquery#2.1.4
│ ├─┬ jquery.cookie#1.4.1
│ │ └── jquery#2.1.4
│ └── modernizr#3.9.0
Forcing the modernizr version to 3.5.0 in bower.json solved the issue:
"dependencies": {
...
"modernizr": "3.5.0"
}
I don't fully understand why modernizr was resolved to different versions in some computers, as in both cases we had the same Zurb Foundation's version pinned, but this was the way we fixed the issue.

Meteor simple-todos tut - Step 2 - Uncaught Error Cannot find module './template.body.js

I have created a debian virtual machine where I have installed meteor version 1.4.2.
I am working on the simple-todos meteor tutorial, blaze view.
I have done everything on step 2 [several times; even to the point of deleting and starting over many times]; I've even done straight c&p of all the code into the various files. I have spent several hours searching google; git-hub, and stackoverflow and have not found anything that seems to relate to my problem.
When I look at the app in the browser, the page is blank ... when I look in the console I have the following error code:
Uncaught Error: Cannot find module './template.body.js'
at require (http://localhost:3000/packages/modules-runtime.js?hash=ab7e8d32b6c7b5a5fa7ae1b65e8225c4f9e30223:119:19) [this error continues with a lot more references and hashes, but I can't post more than 2 links]
If someone could at least point me in the right direction so I can continue to research this, I would be most grateful.

OK, that's weird... I replicated what you were seeing. It happens when you have meteor RUNNING while doing this coding, so it is doing live code update, but the module is not being built/included properly.
All I did was STOP and restart Meteor. And it worked.
Not sure why it is not loading the modules in a rebuild and hot code push, but there you have it, that's the fix.
Here is my shell so you see what I did:
shaunst:~/workspace $ curl https://install.meteor.com/ | sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7784 0 7784 0 0 23942 0 --:--:-- --:--:-- --:--:-- 23950
Downloading Meteor distribution
######################################################################## 100.0%
Meteor 1.4.2 has been installed in your home directory (~/.meteor).
Writing a launcher script to /usr/local/bin/meteor for your convenience.
This may prompt for your password.
To get started fast:
$ meteor create ~/my_cool_app
$ cd ~/my_cool_app
$ meteor
Or see the docs at:
docs.meteor.com
shaunst:~/workspace $ meteor create simple-todos
Created a new Meteor app in 'simple-todos'.
To run your new app:
cd simple-todos
meteor
If you are new to Meteor, try some of the learning resources here:
https://www.meteor.com/learn
shaunst:~/workspace $ cd simple-todos/
shaunst:~/workspace/simple-todos $ meteor npm install
simple-todos# /home/ubuntu/workspace/simple-todos
└─┬ meteor-node-stubs#0.2.3
├── assert#1.3.0
├─┬ browserify-zlib#0.1.4
│ └── pako#0.2.8
├─┬ buffer#4.5.1
│ ├── base64-js#1.1.2
│ ├── ieee754#1.1.6
│ └── isarray#1.0.0
├─┬ console-browserify#1.1.0
│ └── date-now#0.1.4
├── constants-browserify#1.0.0
├─┬ crypto-browserify#3.11.0
│ ├─┬ browserify-cipher#1.0.0
│ │ ├─┬ browserify-aes#1.0.6
│ │ │ ├── buffer-xor#1.0.3
│ │ │ └── cipher-base#1.0.2
│ │ ├─┬ browserify-des#1.0.0
│ │ │ ├── cipher-base#1.0.2
│ │ │ └─┬ des.js#1.0.0
│ │ │ └── minimalistic-assert#1.0.0
│ │ └── evp_bytestokey#1.0.0
│ ├─┬ browserify-sign#4.0.0
│ │ ├── bn.js#4.11.1
│ │ ├── browserify-rsa#4.0.1
│ │ ├─┬ elliptic#6.2.3
│ │ │ ├── brorand#1.0.5
│ │ │ └── hash.js#1.0.3
│ │ └─┬ parse-asn1#5.0.0
│ │ ├─┬ asn1.js#4.5.2
│ │ │ └── minimalistic-assert#1.0.0
│ │ ├─┬ browserify-aes#1.0.6
│ │ │ ├── buffer-xor#1.0.3
│ │ │ └── cipher-base#1.0.2
│ │ └── evp_bytestokey#1.0.0
│ ├─┬ create-ecdh#4.0.0
│ │ ├── bn.js#4.11.1
│ │ └─┬ elliptic#6.2.3
│ │ ├── brorand#1.0.5
│ │ └── hash.js#1.0.3
│ ├─┬ create-hash#1.1.2
│ │ ├── cipher-base#1.0.2
│ │ ├── ripemd160#1.0.1
│ │ └── sha.js#2.4.5
│ ├── create-hmac#1.1.4
│ ├─┬ diffie-hellman#5.0.2
│ │ ├── bn.js#4.11.1
│ │ └─┬ miller-rabin#4.0.0
│ │ └── brorand#1.0.5
│ ├── inherits#2.0.1
│ ├── pbkdf2#3.0.4
│ ├─┬ public-encrypt#4.0.0
│ │ ├── bn.js#4.11.1
│ │ ├── browserify-rsa#4.0.1
│ │ └─┬ parse-asn1#5.0.0
│ │ ├─┬ asn1.js#4.5.2
│ │ │ └── minimalistic-assert#1.0.0
│ │ ├─┬ browserify-aes#1.0.6
│ │ │ ├── buffer-xor#1.0.3
│ │ │ └── cipher-base#1.0.2
│ │ └── evp_bytestokey#1.0.0
│ └── randombytes#2.0.3
├── domain-browser#1.1.7
├── events#1.1.0
├─┬ http-browserify#1.7.0
│ ├── Base64#0.2.1
│ └── inherits#2.0.1
├── https-browserify#0.0.1
├── os-browserify#0.2.1
├── path-browserify#0.0.0
├── process#0.11.2
├── punycode#1.4.1
├── querystring-es3#0.2.1
├─┬ readable-stream#2.0.6
│ ├── core-util-is#1.0.2
│ ├── inherits#2.0.1
│ ├── isarray#1.0.0
│ ├── process-nextick-args#1.0.6
│ └── util-deprecate#1.0.2
├─┬ stream-browserify#2.0.1
│ └── inherits#2.0.1
├── string_decoder#0.10.31
├── timers-browserify#1.4.2
├── tty-browserify#0.0.0
├─┬ url#0.11.0
│ ├── punycode#1.3.2
│ └── querystring#0.2.0
├─┬ util#0.10.3
│ └── inherits#2.0.1
└─┬ vm-browserify#0.0.4
└── indexof#0.0.1
shaunst:~/workspace/simple-todos $ meteor --port 8080
[[[[[ ~/workspace/simple-todos ]]]]]
=> Started proxy.
=> Started MongoDB.
=> Started your app.
=> App running at: http://localhost:8080/
=> Meteor server restarted
=> Meteor server restarted
=> Meteor server restarted
=> Meteor server restarted
=> Client modified -- refreshing (x3)
=> Meteor server restarted
=> Meteor server restarted
=> Client modified -- refreshing^C
shaunst:~/workspace/simple-todos $ ^C
shaunst:~/workspace/simple-todos $ meteor --port 8080
[[[[[ ~/workspace/simple-todos ]]]]]
=> Started proxy.
=> Started MongoDB.
=> Started your app.
=> App running at: http://localhost:8080/
=> Client modified -- refreshing (x2)

I'm experiencing the same.
I did as user Shaun Stoltz suggested (restart Meteor), and it did work. But then I added more files to the imports folder, and the error recurred, now referencing the new file missing 'template...'.
I gave Meteor another restart, and the build worked again.It seems that meteor omits the new files from the build while it's watching. Only upon restart the new files get included. This is a real nuisance as while following contemporary componental approach, i will be creating many small files, and restarting Meteor repeatedly is going to exhaust.
Are there other users experiencing this issue?

Set your project's Meteor version to a previous one:
meteor update --release 1.4.1.3
(Thanks to diaconutheodor)
Source

I am running meteor on a Mac using blaze templating. I have done the following steps and it has worked:
make sure that the import statement is in client/main.js and not in
server/main.js
make sure that 'blaze-html-templates' is installed
ensure that imports folder is typed correctly
Restart the server
If everything else fails, you can reset your project using 'meteor reset'
Hope this helps.

Should I copy files from bower_components of reference them there?

After installing BackboneJS, jQuery etc I have a very large bower_components directory.
├───.idea
│ ├───runConfigurations
│ └───scopes
└───app
├───bower_components
│ ├───backbone
│ ├───jquery
│ │ ├───dist
│ │ └───src
│ │ ├───ajax
│ │ │ └───var
│ │ ├───attributes
│ │ ├───core
│ │ │ └───var
│ │ ├───css
│ │ │ └───var
│ │ ├───data
│ │ │ └───var
│ │ ├───effects
│ │ ├───event
│ │ ├───exports
│ │ ├───manipulation
│ │ │ └───var
│ │ ├───queue
│ │ ├───sizzle
│ │ │ ├───dist
│ │ │ └───test
│ │ │ ├───data
│ │ │ └───unit
│ │ ├───traversing
│ │ │ └───var
│ │ └───var
│ └───underscore
├───css
└───js
What is best practice to reference these? e.g directly, Grunt task to copy bits to the main app, or put the bower_componects inside the ~/app directory?

Don't copy them over to your app - that completely defies the intent of a package manager like Bower! By doing so, you'd take control over these files away from your package manager - and then you're left in the same state as before, manually having to copy over files every time with an update of these dependencies.
Just reference the files inside the bower_components/ directory directly (in your HTML, most likely). If you don't like that location or name, you can have bower put your components some place else, see .bowerrc doc: http://bower.io/docs/config/
I can think of a use for only using specific files from your bower_components directory - but only at build time:
If you write a grunt task that runs only at deploy time and strips away all unused files from the bower_components directory, that of course makes sense and does not go against the idea of a package manager, because it only happens on each deploy, a point when the package manager has no responsibilities.
The only problem you might get with this approach is if you have it end up copying files over to a different directory - because then you'd have to change the references to all files from bower_components before deploying, too. The easy solution is to not duplicate files, but instead, only delete the ones you don't need.

Just leave them in bower_components and refer proper files inside your index.html file. You can do this manually, or use tools like grunt wiredep to do this for you automatically.