Can alternative AMD loaders be used in functional testing with intern? - requirejs

The useLoader configuration for specifying another AMD loader to use does not seem to be used in functional test modules.
I want to load a JSON file into a javascript object to use in my functional test suite by using a requireJS JSON plugin (https://gist.github.com/millermedeiros/1255010) but it does not work due to what I assume is the plugin looking for requireJS specific constructs:
TypeError: Cannot read property 'isBuild' of undefined
at Object.load </home/dev/public_html/gold_widgets_15644/web/assets/js/json.js:27:24>
at injectPlugin <node_modules/intern/node_modules/dojo/dojo.js:608:12>
at <node_modules/intern/node_modules/dojo/dojo.js:543:7>
at Array.forEach <native>
at forEach <node_modules/intern/node_modules/dojo/dojo.js:220:19>
at execModule <node_modules/intern/node_modules/dojo/dojo.js:535:5>
at <node_modules/intern/node_modules/dojo/dojo.js:582:7>
at guardCheckComplete <node_modules/intern/node_modules/dojo/dojo.js:566:4>
at checkComplete <node_modules/intern/node_modules/dojo/dojo.js:574:27>
at onLoadCallback <node_modules/intern/node_modules/dojo/dojo.js:656:7>
What's the best way to include json from a file in a functional testing module if alternative AMD module loaders such as requireJS are not supported in functional tests?
Should one just use node's fs library in conjunction with JSON.parse?

You're correct, functional tests run with the default loader. A functional test just drives the browser -- it doesn't run in the same environment as the application under test.
You can use both AMD and CommonJS libraries in your functional tests. For example, you can install the Dojo npm module and add it to the packages list in your test config to use dojo/text (and any other Dojo utility functions). You can also load Node's fs module using the dojo/node module included with Intern, like:
define([ 'intern/dojo/node!fs', ... ], function (fs, ...) {
...
});

Related

Using "module":" ES2020" instead of commonJS in nodejs project

is it possible to use ES2020 in tsconfig instead of coomonjs in nodejs project. Because when I use commonjs typescript when compiled generates a lot of javascript.
ES2020 and commonjs pertain to different things when configuring your tsconfig.json
ES2020 will go in the lib array. It refers to which language features to include.
commonjs will go in the module property. This refers to which module system you are using (ie. are you using require and module.exports syntax (commonjs), or import and export syntax (esm)?).

How can I load a global script (<script src="">) in Jest

I need to make a JavaScript script available as a global script tag for a unit test in Jest.
I understand that Jest uses jsdom and in jsdom there is an api that allows to initialize the DOM and load script but I cannot seem to find a way on how to do this in Jest?
If you do not need to test the script itself, which, given the fact it is an external library, you shouldn't, you can mock it globally.
First of all you need to setup a jest setupFile, this file will be executed before test execution and the mocks available there should remain available for each test file, to do so write something like this in package.json or, better, in jest.config.js
"jest": {
"setupFiles": [
"<rootDir>/jest/globals.js"
]
}
Then create that file and write your global mocks there.
Now you will say "'Duh'? How do I mock the external library imported through the tag script?" Well, what I found useful for this and a number of other reason is to wrap the imported library in a separate module, this way you can use the wrapper throughout your code instead of using directly the globally imported external library, which will give you the possibility to mock the said module globally and voilĂ , it is done!
You can simply use require to load your script.
However, keep in mind that the script must be saved locally.
require('relative/path/to/your/script')
Some more interesting information here :
https://info343.github.io/jest.html

How do I write TypeScript tests that don't include the classes under test in the transpiled test code?

I have a TypeScript project that compiles down to a single JS file in /dist.
I have Jasmine tests, also written in TypeScript, that reference the various classes they test with references like:
/// <reference path="../../../src/script/classUnderTest.ts" />
When I compile the tests the TypeScript compiler pulls in all the referenced classes and I get a single JS file containing the test code and the code under test.
This actually works fine for just running the tests, but now I'd like code coverage too. From what I can tell, to get Istanbul to work I need to have the code under test separate from the test code. Also it would be nice to be testing exactly the JS file that will be live.
So, how can I get the type safety and autocomplete benefits of "/// reference" whilst using my compiled JS file when the tests are actually run?
(Or am I barking up the wrong tree entirely?)
Note, I am building this on a Mac, so from what I've read Chutzpah is not currently an option. I'm also currently using only npm scripts to do builds. I'd prefer to not bring in grunt or gulp unless it's absolutely necessary.
So, how can I get the type safety and autocomplete benefits of "/// reference" whilst using my compiled JS file when the tests are actually run?
Don't using TypeScript's --outFile option (few other reasons). Instead use modules e.g. --module commonsjs and a module loader e.g. webpack.
More
Browser quickstart : https://basarat.gitbooks.io/typescript/content/docs/quick/browser.html
Modules:
https://basarat.gitbooks.io/typescript/content/docs/project/modules.html

Output require() construct with AMD generation

I currently have a set of RequireJs modules defined as:
require(['dep1', 'dep2'], function(dep2, dep2) {
...
});
I'm looking to convert these into TypeScript modules, however the AMD generation outputs them with the define() construct:
define(['dep1', 'dep2'], function(dep2, dep2) {
...
});
I can see how they would essentially be equivalent. However I have always worked on the following basis:
Define: When you want to be able to pass the module into other modules.
Require: When the module just needs to be executed
Are these assumptions redundant? Or is there a way to instruct TypeScript to output the require() construct for a module?
Are these assumptions redundant?
Yes. require should only be used when you want to lazy load.
is there a way to instruct TypeScript to output the require() construct for a module
Yes. Use the requirejs definition : https://github.com/borisyankov/DefinitelyTyped/blob/master/requirejs/require.d.ts and write code to call the require function manually.
You can write one file manually using require() to load other modules or use the data-main property on the element loading require.js.

bower init - difference between amd, es6, globals and node

I am creating my first Bower component. After running bower init the script asks me 'what types of modules does this package expose?' with these options:
amd
es6
globals
node
what is the difference between these options?
If you don't know, it's quite likely globals is the right answer for you.
Either way, you need to understand:
what is and why AMD
what is a nodejs module
what is ecmascript 6 and especially es6 modules
[UPDATE]
This feature was introduced very recently in bower and is not documented at all yet (AFAIK). It essentially describes the moduleType, which states for what module technology the package is meant to be consumed (see above).
Right now, It doesn't have any effect apart from setting the moduleType property in the bower.json file of the package.
See https://github.com/bower/bower/pull/934 for the original pull-request.
[UPDATE #2]
A few additional points, to answer comments:
right now AFAIK there is no validation done on the moduleType property - which means that people are technically allowed to use whatever value they want for it, including angularjs if they feel inclined to do so
the bower committee seems to not be keen toward the inclusion of additional non-interoperable/proprietary moduleTypes (think composer, angular, etc) - which is easily understandable, but yet again, nothing really prevents people from using the moduleType value they want
an exception to the previous is the (somewhat) recent inclusion of the yui moduleType, so, there are "exceptions" to be made, assuming they are part of a concerted plan
What I would do if I were to author a package for a not-listed package manager and publish it on bower?
I would author an es6 module, and use / patch es6-transpiler to output the package format I need. Then I would either/and:
petition the bower guys to include my package technology as a choice (based on the fact it's supported by es6-transpiler as a target)
publish my package including both the es6 module version of it and the transpiled XXX version of it, and use es6 as a moduleType
Disclaimer: I don't have real-life experience authoring angularjs modules.
Initial
I'm using bower init for first time too.
The options should refer to the different ways to modularize some JavaScript code:
amd: using AMD define, like requirejs.
node: using Node.js require.
globals: using JavaScript module pattern to expose a global variable (like window.JQuery).
es6: using upcoming EcmaScript6 module feature.
In my case I wrote a Node.js module dflow but I'm using browserify to create a dist/dflow.js file that exports a global dflow var: so I selected globals.
Other Updates
The command I used to browserify dflow as a window global object was
browserify -s dflow -e index.js -o dist/dflow.js
I changed it cause I prefer to use require also inside the browser, so now I am using
browserify -r ./index.js:dflow -o dist/dflow.js
and so I changed the bower.moduleType to node in my bower.json file.
The main motivation was that if my module name has a dash, for example my project flow-view, I need to camelize the global name in flowView.
This new approach has two other benefits:
Node and browser interface are the same. Using require on both client side and server side, let me write only once the code examples, and reuse them easily on both contexts.
I use npm scripts and so, I can take advantage of ${npm_package_name} variable and write once the script I use to browserify.
This is another topic, but, it is really worth that you consider how it is useful the latter benefit: let me share the npm.scripts.browserify attribute I use in my package.json
"browserify": "browserify -r ./index.js:${npm_package_name} -o dist/${npm_package_name}.js"
Just for reference, this is precisely what bower specifies regarding the module types:
The type of module defined in the main JavaScript file. Can be one or an array of the following strings:
globals: JavaScript module that adds to global namespace, using window.namespace or this.namespace syntax
amd: JavaScript module compatible with AMD, like RequireJS, using define() syntax
node: JavaScript module compatible with node and CommonJS using module.exports syntax
es6: JavaScript module compatible with ECMAScript 6 modules, using export and import syntax
yui: JavaScript module compatible with YUI Modules, using YUI.add() syntax
Relevant link: https://github.com/bower/spec/blob/master/json.md#moduletype

Resources