How to test files that use browserify-shim global's in Jest? - browserify

I'm downloading the google maps API v3 via a script tag, and I'm adding the dependency to my modules with the following (relevant) package.json configuration:
"browserify-shim": {
"google": "global:google"
}
And I can add the dependency in my files with the following:
var google = require('google');
When I run my code in the browser, it works fine.
The problem is, when I run my tests with Jest, it tells me that it can't find the 'google' module:
Error: /src/app/assets/javascripts/__tests__/helpers-test.js: Cannot find module 'google' from '/src/app/assets/javascripts/__tests__'
Note:
This dependency is being required in the file that I'm testing, not the test itself. I find this confusing since I thought that Jest mocks all dependencies unless it is specified otherwise, but from what I can see, it first needs to correctly satisfy the dependencies before mocking.
Any ideas of what am I missing or what approach should I take?

You'll need to alias 'google' properly in your package.json, see here.

Related

import { PluginConfig, ProtractorPlugin } from './plugins';

I am getting this issue when running the spec file.
before updating my dependencies it is working fine.
I was trying the update dependencies in the package.json
so I enter the this command in the terminal npm update --save.
You are receiving this error because there is a problem with your typescript compiler. You need to add #types/node and other typescript dependencies to fix this error. If you run your tests in javascript this problem should not arise. So please check your tsconfig and see if your are using ES6 libraries. Also check if the types for selenium, node, jasmine and jasminewd2 are added in your package.json.

What is the difference between plugins and dependencies in the Vue.js UI?

When using the ui you have the option of installing dependencies and plugins.
I am confused about the difference between both of these.
For instance, I can install axios as a dependency and a plugin.
Do I need to do both? Why do one over the other?
My current understanding is that dependency is just that, it adds a package to your project while a plugin will add configuration as well.
Am I correct in thinking that?
A plugin is exactly what you described. It 'plugs into' another piece of software and adds functionality. A dependency on the other hand means that your software simply depends on something to function correctly - usually code.
In your axios example:
The axios plugin installs another prototype property on your Vue instance (this.$axios.. or whatever it is called) so it definitely adds a feature to Vue.
You could also only use Axios by itself and import it in the files you need
import axios from 'axios'. You don't add any feature to Vue itself - you just use another software within your app. Axios here is a dependency.
I will probably not be completely correct, but my understanding is
Plugins vs Dependencies
Command line
dependencies are installed via the command line as npm install <name> or npm install --save <name> to add the dependency to package.json
plugins are installed via the command line as vue add #scope/vue-cli-plugin-<name> or with the shorthand vue add #scope/<name>
Installation
dependencies are placed into your projects node_modules folder
plugins will invoke the generator.js script of the plugin being installed. This generator.js may add dependencies to package.json, add import statements to files in your project, add/alter existing components, or any of the various things listed under the generator api docs
Usage
dependencies will need to be imported into any file you use them in, or imported globally, before they are able to be used
plugins often will have already set up global imports, making them available in every file. Plugins will also often add additional scripts to package.json (which show up as tasks in the vue ui)

Using 3rd Party AAR in React-Native Android App

I am attempting to build a React-Native Android app that utilizes functionality provided by a 3rd party's AAR but am unclear as to both the process in general as well as the required specifics.
I have successfully built an Android Studio app using this AAR.
And, I have scoured the documentation here (and postings elsewhere): https://facebook.github.io/react-native/docs/tutorial but remain unclear as to the correct process.
My initial attempts have centered around trying to find the correct "implementation" and/or "compile" commands in the gradle files coupled with the correct "import" statement(s) in the source file(s).
I had assumed getting those correct would afford access to the classes in the AAR, but after numerous unsuccessful attempts am now wondering if there is something more that needs done.
For example, do I need to construct a bridge module as described here: https://medium.com/#yushulx/react-native-bridging-modules-for-android-from-scratch-c651eeee7872 ?
Based on the few questions/answers I found on this topic, I have placed this code in the "allprojects" section of my top-level build.gradle file:
flatDir {
dirs 'libs'}
}
...and have included the following in the "dependencies" section of the build.gradle file:
fileTree(dir: 'libs', include: '**/*.aar')
.each { File file ->
dependencies.add("compile", [
name: file.name.lastIndexOf('.').with { it != -1 ? file.name[0..<it] : file.name },
ext: 'aar'])
}
...and have included various forms of "import" statements in my app.js file, like:
import {EENMediaPlayerListener} from 'EENSDK';...
When I execute "react-native run-android" I receive the following error message:
error: bundling failed: Error: Unable to resolve module `EENSDK` from `C:\Users\Chuck\EE\App.js`: Module `EENSDK` does not exist in the Haste module map
EENSDK.aar is located in the 'C:\Users\Chuck\EE\android\app\libs' directory.
If I remove the "import" statement, it compiles without errors.
So, do I just have the "compile", "implementation", and "import" statements wrong, or is there something more (and if so, where can I read about that)?

How to run aurelia-plugins/aurelia-plugins-google-places-autocomplete locally

I have installed this aurelia plugin in my project: https://github.com/aurelia-plugins/aurelia-plugins-google-places-autocomplete which is basically an Aurelia wrapper for google places autocomplete.
Unfortunately I'm experience a "regeneratorRuntime is not defined" issue when using it (It has been reported in the repo). And the reason seems to be the way that async/await are transpiled. I have found a possible solution to fix the issue as seen here: Babel 6 regeneratorRuntime is not defined with async/await
I have cloned the repo and installed now I just need to be able to run it locally to test it out. Does someone know how I can run that repo locally. Thank you very much.
Usually what I do when I want to test a plugin is I will create test project where I run the plugin as a feature. Features work just like plugins except they are local to your project's structure. Instead of doing
aurelia.use
.plugin('aurelia-plugins-google-places-autocomplete', config => { \\...
You will do
aurelia.use
.feature('aurelia-plugins-google-places-autocomplete', config => { \\...
This is assuming you place the plugin in src\aurelia-plugins-google-places-autocomplete.
This is a story that I would like to see us come up with a pattern for. Maybe we'll add something to the skeleton-plugin project that will help with this.

npm: dependencies vs devDependencies with bundled dependencies

Using the search I already found some great answers to similar questions, but still I am not sure if I understood it correctly.
From these answers I learned that dependencies are required to run the application while devDependencies are only required while developing (like unit tests).
But how about this: My application depends on jQuery, but during a build step (with the help of my devDependencies), everything is bundled into one file. In this case, should I list jQuery as dependency or as devDependency?
To make my point more clear take a module like this:
define(['jquery'], function($) {
// use jQuery in this module
})
Later on, this module will be compiled into somehing like application.build.js which then contains this module and the jQuery dependency.
Since the end result is the same, there doesn't seem to be a definite rule here, but I found a couple of discussions on the matter:
If you're building an application
https://github.com/webpack/webpack/issues/520
A browser app built by [insert build tool/bundler] has no runtime node dependencies, and thus all frontend dependencies should be listed as devDependencies. The dependencies vs devDependencies naming convention stems historically from node being a server side package manager (...) It is as far as I can tell harmless to list frontend dependencies under dependencies, but it is wrong.
(...) as a general recommendation for everyone, move everything into devDependencies until it is actually needed under dependencies.
If you're building a library:
https://github.com/inuitcss/inuitcss/issues/225
In many frontend projects, all code served to the browser is compiled, there are no runtime dependencies. This would mean that there are no dependencies, only devDependencies – all dependencies are included in the build done during development.
One could also argue that dependencies are required for development as well, so it would be okay to list everything unter dependencies.
I think the fact that we have the optional distinction indicates a reasonable way to use them. It makes sense (to me) that the dependencies designation would represent the 'minimum viable' code to use and as an indicator of what's nonessential for something to work.
As I see it, anything that goes on to become part of the production code is a dependency.
Epilogue
Personally, I agree more with the last quote. It makes sense that dependencies tells us what the application code needs to run, and devDependencies what the developer needs to build/deploy/whatever the application/library.
One caveat though is that if someone npm installs your library to use the bundle as a module in their own application, they will download a lot of dependencies they don't actually need.