We Keep Coding

How do I pass in an entire JSON as the cypress.env through the command line in Cypress?

I am familiar with adding individual environment variables through the CLI by entering:
./node_modules/.bin/cypress run -- --env itemToOverride="val"
But let's say I have an entire JSON that can be a valid cypress.env, how do I pass that in via CLI without having to add each item from the JSON individually?
For example, let's say I have env1.json and env2.json which both have valid structure for my test, but I want to be able to run all my tests with env1 then env2? Similar to:
./node_modules/.bin/cypress run -- --env env1.json

For others that stumble here and want a working answer: The easiest solution to this would be to create a config folder in your project directory containing all the environment JSONs you want. I wrote a script to take an environment file's name as an argument when running it. I decided on a bash script, but you could also use an npm script to achieve this. Basically, to run the tests in "env1" you would type on your command line:
./cypress --env=env1
The way I achieved this was by copying the selected JSON from the config folder to the main directory, then renaming it 'cypress.env.json'. This is a setup function in my bash script to get you started:
function doSetup {
echo "Selecting environment variables from $ENV.env.json"
cp ./cypress/config/"$ENV.env.json" ./
mv "$ENV.env.json" "cypress.env.json"
}
It's an obscure problem that does not have very many answers online, but I hope this helps!

how to change the test file run order in cypress in run time

I have 3 different test files
1- testfile-1.js
2- testfile-2.js
3- testfiles-3.js
i can change the test file running order using testfiles feature in cypress.config file but i want to change the order runtime not hard coded.
looking for the solution
Regards

Change the file name to something like this in case you don't want to use testFiles: [] in your cypress.config.
01-testfile.spec.js
02-testfile.spec.js
03-testfile.spec.js

You can comma-separate the file names on the command line,
yarn cypress run --spec "testfile-1.js,testfile-2.js,testfiles-3.js"
Not sure if that guarantees the order though.
If no luck with that, it would be possible to guarantee the order by running with a special script (but it's more work).

i found a way
{
"chromeWebSecurity": false,
}
paste this in cypress.json and it will allow the external iframes to work in cypress

i18n-js translations not updating with additional translations in .yml

I have been reading about this for days, and nothing seems to be working. I have seen a lot of documentation of this issue, but none of the work arounds are working for me.
I have :
Rails 5.0.1
* sprockets (3.7.1)
* sprockets-rails (3.2.0)
* i18n (0.7.0)
* i18n-js (3.0.0.rc15)
config/i18n-js.yml
translations:
- file: "app/assets/javascripts/application/i18n/translations.js"
only: '*.js*'
config/application.rb
config.middleware.use I18n::JS::Middleware
When I add new translations to the corresponding yml file, the i18n/translations.js does not update to include the new .yml translations.
For example, in en.yml:
en:
form_error:
tos_check: "You must agree to Lexody's Terms of Use to continue."
choose_city: "Please select a city from the menu."
cancel_reason: "Please provide a reason for cancelling."
$('.prompt').html('<p style="color:#e57373">' + I18n.t('form_error.cancel_reason') +'</p>');
returns: [missing "en.form_error.cancel_reason" translation]
I have tried:
Deleting translations.js and run rake i18n:js:export
rake tmp:cache:clear
rake assets:precompile
Does anyone have another solution I can try? Thanks!!

Update
After looking at the additional configuration files, this config/i18n-js.yml seems suspect:
translations:
- file: "app/assets/javascripts/application/i18n/translations.js"
only: '*.js*'
According to the export configuration docs, the only key refers to the translation keys to be exported, not the filenames. So '*.js*' will match nothing, causing no translations to be exported.
Change this file to read:
translations:
- file: "app/assets/javascripts/application/i18n/translations.js"
only: '*'
(Original answer below)
Working example
Here's a minimal, working example that produces expected behavior with the i18n-js gem:
#!/bin/bash
rails _5.0.1_ new .
echo "gem 'i18n-js', '3.0.0.rc15'" >> Gemfile
echo " NEW_KEY: NEW_VALUE" >> config/locales/en.yml
bundle install
bundle exec rake i18n:js:export
grep -o '"NEW_KEY"' public/javascripts/translations.js
For me, running the above script outputs "NEW_KEY" on the last line, as expected (demonstrating that NEW_KEY is correctly added to public/javascripts/translations.js after running i18n:js:export in a fresh Rails installation), which means something else is going on in your local project.
Further investigation
In order to know what else exactly is going on, you'll have to further investigate exactly what configuration you've changed locally when compared to a fresh Rails installation.
(Note that the easiest way to do this is to provide a Minimal, Complete and Verifiable example, such as a link to a GitHub repo that produces your issue exactly.)
you say "the i18n/translations.js does not update to include the new .yml translations.", but the default path that gets updated is public/javascripts/translations.js. If you're using a non-standard path for your translations.js file, do you have additional configuration for this in config/i18n-js.yml? (If so, please share the entire contents of this file).
Have you confirmed that the new translation doesn't show up in translations.js at all (e.g., using a grep command like the one above)? Or is it possible that the issue is related to the asset pipeline configuration instead?

Not sure if you mean dev or prod env. I had a similar problem in my dev env and I solved it by adding config.middleware.use(I18n::JS::Middleware) to config/application.rb. You can check it here. Hope it helps.

In the .yml file, check for a colon after the language code.
Your example reads:
en
form_error:
cancel_reason: "Please provide a reason for cancelling."
Try:
en:
form_error:
cancel_reason: "Please provide a reason for cancelling."
I haven't tried exercising an example with this. However, the .yml files in the projects I have copies of all have colon after the language name. And it's just the sort of infuriating typo that might be invisible to someone close to it. Grr!

It seems that you have the English translation but is trying to access french locale instead.

How to run npm {bin: script.js} with parameters

I am planing to make something similar as lodash custom builds. So in general I want to let user write command like:
lodash category=collection,function
Which create custom module just with category i specified
I read few tutorials how to run scripts with npm bin. Just in case I understand something wrong I write it what i think.
So if I have package.json with this part:
"main": "bin/index.js",
"bin": {
"snippet": "bin/index.js"
},
and I npm install -g console should listen for command snippet and when i write it it run the script index.js in folder bin.
This part looks it works correctly for me. When i have something simple in my index.js i.e. console.log('It Works').
In standard situation you want to let user pass parameters to script. So i found out that all parameters should be in variabile process.argv.
The process.argv property returns an array containing the command line
arguments passed when the Node.js process was launched. The first
element will be process.execPath. The second element will be the path
to the JavaScript file being executed. The remaining elements will be
any additional command line arguments.
So i simply console.log it and run script.
If I run script via command snippet -f -a
Output is : [ 'node', 'path/to/file' ]
If i run script via node bin/index.js -f -a
Output is: [ 'node', 'path/to/file', '-f', '-a' ]
I dont understand that, its same script but different output. However I try it looks like when i call script via bin command it never pass parameters.
Is here someone who have experience with this? And advise me what i am doing wrong?
Or alternativly is there some other way how to make this?
Thanks for any advise.

It take a time however I have a solution now so hope it help someone later.
Where was a problem:
I noticed that my windows has default program to run .js file set to NODE.js and because it's default setting of course all .js files are opening without parameter.
So in my case every .js file open with NODE no matter what, I try to changed it to open with something like PSPAD or similar but this basicly open editor instead of execute file.
How did I fix it:
Instead of using executing .js directly with something I make my ./bin/index.js binary file (basicly removed .js suffix)
Added #!/usr/bin/env node on top of index file
Goes to package.json and changed all dependency on ./bin/index.js to ./bin/index
Woala! it works :)
p.s. As I mentioned at start I believe there is an option to run this with .js as well but I wasn't able to find it. So please if anyone will find it let me know.
Thanks

Using DOH to unit test a non-Dojo javascript project

Essentially I need help understanding this blog post:
http://www.sitepen.com/blog/2008/04/15/unit-testing-custom-code-with-the-dojo-objective-harness/
I want to use DOH to unit test an existing javascript project and I do not want to restructure that project to look like a Dojo widget. My project is structured like so:
project/
scripts/
doh/
...
tests/
testA.js
project.js
tests/
tests.html
index.html
tests.html is a page with a single link to:
../scripts/doh/runner.html?testModule=scripts.tests.testA
testA.js does not appear to be loading, and I'm not sure what code should go in it so that it loads correctly as a test suite and also has access to the classes defined in project.js.

Does your browser give any indication in its debugger tools as to whether it tried to load something called testA.js, and if so, where from?
If you have a path issue (it may be looking for 'scripts' as a sibling directory to your dojo directory), you can give DOH a hint in the runner URL as to how to map packages, e.g. &registerModulePath=scripts,../../scripts (this maps 'scripts' to '../../scripts'; you'll need to tweak that as appropriate as I can't see where your Dojo directory is)
Typically, you point 'testModule' at a module file, which is a file which simply pulls in test fixtures, but I think you can get away with just pointing at a test fixture file itself. That just needs to call doh.register with some tests, and doh.run() to kick it all off.