How to mock/access dojox using Jasmine and requireJS - dojo

I'm using requireJS with karma and jasmine to test Dojo code.
As we know, require brings in all dependencies within each file, which is fine, however I get a script error when any of the files have language files (e.g. dojox/date/buddhist.js) as a dependency.
The language file is laid out as follows:
define([
"..",
"dojo/_base/lang",
"dojo/date",
"./buddhist/Date"
], function(
dojox,
lang,
dd,
BDate
) { /* etc etc */
When referencing e.g. "dojo/_base/lang" this is easy to map to the file, however, notice the mapping to dojox is ".." which actually goes back to a directory and not a single file.
This is the error I get in the terminal or console in browser:
Error: Script error for "dojox", needed by: dojox/date/buddhist, dojox/date/buddhist/locale, dojox/date/hebrew, dojox/date/hebrew/locale, dojox/date/islamic, dojox/date/islamic/locale
http://requirejs.org/docs/errors.html#scripterror
I've tried defining dojox in my test-main file but same error.
So what I need to do is to mock dojox, is there a workaround for this?

I have fixed this by changing the dojox date files to reference an actual file:
Changed ".." to "dojox/main" and mapped to that file.
I changed this within the actual dojo files as I use a copy of them in my test project, not sure if this would work in production but I think it would as it seems dojo have switched to this also in later versions.

Related

How to use a template HTML with Snowpack 3?

I am new to Snowpack and I have a Template.html' file in my source folder that I would like Snowpack to read and produce an index.html` in the destination output folder. It would also be nice if I can use some variables in the template that Snowpack would simply substitute from the environment or configuration file. Any idea how to achieve this?
If I understand correctly, you are looking to use an alternative to index.html. I'm not sure if you are using react or a different framework, but in case you are using react, I found a solution.
This context is for flavor and is not related to the question, but I'll share in case it is helpful to others. In my case, I wanted to block the following warning on my production build (due to react-scripts, not snowpack):
Loading module from “http://localhost:3000/dist/index.js” was blocked because of a disallowed MIME type (“text/html”).
This is because snowpack requires the following script tag in index.html to generate your pages:
...
<script type="module" src="/dist/index.js"></script>
...
I don't need snowpack in production at this time ---I'm just here for the module hot reloading for now --- so I want to suppress this warning with an alternative index.html file, just for snowpack so that it has this script tag.
Solution:
So for your case where you want to use variables in snowpack --- but not your production build (or other run scripts for that matter) --- you can do the following:
Create a template with the above script in your index.html body, plus whatever other vars you need. Name it something other than "index.html". I went with indexsnowpack.html for simplicity.
Add the following route (Docs here) to your snowpack.config.js file in your apps root directory:
module.exports = {
...
routes: [
{
match: "routes",
src: ".*",
dest: "/indexsnowpack.html"
}
]
...
}
BEWARE: The above solution will match all paths to your new indexsnowpack.html file. So if you are not using a single-page application setup, you'll run into some hiccups. Further, if you have other routes defined (e.g., for api calls), place those above this route so that this route functions as a fallback for all calls except your api.

How to work with css and js files in moodle plugin

I need to develop a plugin for Moodle, and i need to have some js and css files in plugin. But i have the next problem - how to work with them from installed plugin? Of course, i can hardcode their path via to moodle structure, but it's a very dirty and bad way. Also, i know that i can place all js and css code inline, but i think that it's a bad decision too. Is there a built-in way to serve assets from plugin? I tried to find it in documentations, but found nothing.
Thanks
I assume you want to know how to include CSS and JS files into your plugin.
You can include a JS file via the command:
$PAGE->requires->js( /relative/path/your_script.js');
You can then call a JS function once the page has been downloaded with the command:
$PAGE->requires->js_init_call ( your_JS_function_name, array_of_parameters_here, bool: on DOM ready);
For example:
$PAGE->requires->js_init_call('init', array($USER->lang), true);
Be sure to make the $PAGE available with global $PAGE;, first.
Your CSS file can be named styles.css and put into the root folder of your plugin. The file will be automatically read by the system and included. It will take precedence over (will overwrite the settings of) the system CSS files. After that you will have to reload the theme caches.

PHPUnit autoloader error: Class 'Yii' not found

I am trying to start PHPUnit testing.
I am using composer to load PHPUnit 4.5 , Yii 1.1.14 and some custom Yii packages that we have built.
Inside those custom packages, we autoload some files that set some aliases using the Yii class.
When running our application, we include the base Yii file manually, and then run the composer generated autoloads.
The trouble is, when we run PHPUnit.. the composer autoloads get run first. Even when specifying a bootstrap file with the include:
bin/phpunit --bootstrap carcass/phpunit.bootstrap.php
Leading to the following Exception:
Fatal error: Class 'Yii' not found
In fact it appears the autoloads are run even before the -- options are parsed:
bin/phpunit --help
results in the same error. Removing the autoloads allows PHPunit to run.
Is there any way around this?
I tried placing an autoload for the Yii base file in our main composer.json, but the sub-packages' autoloads get run first.. same error.
I also tried placing an autoload for the Yii base file in each of the sub-packages.. but then we get redeclaration errors as composer uses require. I'm also not a massive fan of this option as it rigidly defines where the Yii definition comes from to sub-packages that don't really need to know.
As the autoload classmap section is run first before all the files sections (including those from the sub-packages).
Placing the yii and YiiBase files in the classmap of the main composer.json for our project solved this issue:
"autoload": {
"classmap": [
"composer_packages/yiisoft/yii/framework/YiiBase.php",
"composer_packages/yiisoft/yii/framework/yii.php"
],
"files": [
...
]
}

UglifyJS file watcher in IntelliJ minifies already minified files during build

I have an UglifyJS file watcher set up in IntelliJ IDEA, and it works great while I'm editing -- I modify the source js, the minified version gets created next to it automatically.
However, when I run an Ant build, and it copies the minified versions into the build working dir, the watcher "helpfully" creates doubly minified versions of them (*.min.min.js) in the build working dir, not ok.
I've set the Scope of the watcher to the 'src' module, but apparently that doesn't do what you'd think it would, because the doubles get created when Ant copies files into the 'build' module. Happens when I use IDEA to manually copy a single file from src to build too.
I don't see how to set this up to include *.js but exclude *.min.js, which is really the right thing. (Seems so sensible that Uglify should have it built in, but far as I can see it doesn't.)
Other than getting rid of the watcher and scripting the build do the minification, or copying only the original js versions and letting the watcher (re)create the minified ones, what's the best way to go here?
Got this working, thanks to a helpful commenter on the IDEA forum. The key is setting up a custom Scope, which I tried to do before but failed.
Pattern I ended up with was this, for anyone with similar needs:
file[src]:*.js&&!file:*min.js*
Making the 'src' module current then opening the dlg and selecting it from the dropdown in the main watcher config window apparently doesn't actually filter by that module. Clicking the ... btn, then choosing it from the dlg that opens does, plus I added an explicit filename pattern to exclude already minified files too.
Works great now, far as I've tested (both a minimal Ant test and manually copying a file to 'build' in IDEA).
This is an old question, and perhaps the Watchers didn't have this functionality at the time.
Using JetBrains 'macro' codes makes the 'min.min.min.js' problem go away.
$FileNameWithoutAllExtensions$.js -m --source-map -o $ContentRoot$\prod\js\$FileNameWithoutAllExtensions$.min.js
I always set 'Scope' to 'Current File', too; why run uglify on files that haven't been altered? (I'm assuming that any 3rd party JS libraries are already minified).

IntelliJ not recognizing typescript named module declarations

I have a situation where my module names need to be in a certain format. Typescript is fine when I do this:
// knockout interfaces, this is knockout.d.ts
declare var ko: KnockoutStatic;
declare module "core!lib/knockout" {
export = ko;
}
And then in my file that uses it:
import ko = require('core!lib/knockout');
IntelliJ doesn't like it though. It says "cannot find external module 'core!lib/knockout'. I'm using the latest stable version (14.1) and this happens with the in-built 1.4 compiler and a custom one.
I guess this may be a Jetbrains bug?
If you add this to the file with the import statement the error will probably go away
/// <reference path="test.ts" />
The real problem I think is that the configuration isn't fully correct. Is the config root correct or are you maybe using version control?
Relevant bits from the link:
From the Scope drop-down list, choose the scope to apply the compiler in. The available options are: – Project Files: all the files within the project content roots (see Content Root and Configuring Content Roots).
– Project Production Files: all the files within the project content roots excluding test sources.
– Project Test Files: all the files within the project test source roots.
– Open Files: all the files that are currently opened in the editor.
VCS Scopes: these scopes are only available if your project is under version control.
– Changed Files: all changed files, that is, all files associated with all existing changelists.
– Default: all the files associated with the changelist
See https://www.jetbrains.com/idea/help/transpiling-typescript-to-javascript.html