Unfortunately due to using cucumber and writing out scenarios I end up with incredibly long file names which windows complains about. Is it possible to override the naming for the files?
I'm assuming you're using the Nightwatch framework since you've tagged it in your post.
It looks like screenshot filenames are defined in nightwatch/lib/api/client-commands/end.js at line 26 of the latest repo const prefix = '${this.api.currentTest.module}/${this.api.currentTest.name}';.
The screenshot path is defined in your nightwatch.json:
{
"test_settings" : {
"default" : {
"screenshots" : {
"enabled" : true,
"on_failure" : true,
"path" : "./screens"
}
}
}
}
It appears your have a few options:
Modify the code in end.js to use a custom naming scheme, and live with a custom framework
Shorten your test module names or test names
Shorten your screenshot destination path in nightwatch.json - unlikely to solve anything since you're saying it's the filenames that are the problem.
This should be possible by using the filename_format option, since:
#2023 was merged
Related
Given the following
/**
* #param {{bar?: string|null}} [param0]
*/
const foo = ({bar = null} = {}) => bar;
Typescript 3.7.2 reports
var bar: string | null
Binding element 'bar' implicitly has an 'any' type.ts(7031)
The JavaScript code works how I want it to, but how can I write the jsdoc hint so that TypeScript understands that the destructured bar variable is string|null not any?
Update with correct answer
The problem found is actually your tsconfig and how the JavaScript type checking works with it. The option that is causing the difference between your config and mine is the strict property. According to the config documentation:
Enabling --strict enables --noImplicitAny, --noImplicitThis, --alwaysStrict, --strictBindCallApply, --strictNullChecks, --strictFunctionTypes and --strictPropertyInitialization.
Adding each of those options to my tsconfig, I discovered that disabling two of those options would get rid of the reported error. Those options are:
--strictNullChecks
--strictPropertyInitialization (because it can't be enabled without the --strictNullChecks option)
When I disabled those two, it was finally happy with the result.
I copied the example into a TypeScript file to see if it had a similar problem.
The TypeScript version reported no errors with the same exact type signature, but the JavaScript version was ignoring the JSDoc altogether. However, looking at the rest of the code, it still was registering the bar variable as being of type string|null.
Coming to this conclusion, it is likely a bug in the JavaScript type checking and how it works with those options despite neither of those options seemingly being related to this case.
EDIT:
I've checked and it looks like there is a bug already logged for this on the TypeScript repo:
https://github.com/microsoft/TypeScript/issues/31372
Previous solution (which didn't work)
You should be able to do this easily. Maybe remove the square brackets from the param name in the jsdoc comment. This example works fine:
/**
* #param {{bar?: number|null}} _
*/
const foo = ({ bar = null } = {}) => {
// do stuff with bar
}
The tsconfig that I have looks like this:
{
"compilerOptions": {
"checkJs": true,
"allowJs": true,
"outDir": "node_modules/.tmp/",
"noImplicitAny": true
},
"include": [
"index.js"
]
}
Here is the repo that has this code you can use to check on your side, too:
https://github.com/cwadrupldijjit/js-typescript-checking
The version of TypeScript that this was tested in is 3.7.2
EDIT:
Checked out the square brackets vs non-square brackets and it looks like it doesn't matter. TSC is fine with it either way.
I had some issues with destructuring assignment shorthand when auto formatting JavaScript and TypeScript code in Visual Studio Code.
I got result like this:
var {
check,
validationResult
} = require("express-validator/check");
but I need it to looks like this:
var { check, validationResult } = require("express-validator/check");
I have Beautify installed, and in my settings:
{
"editor.wordWrapColumn": 160,
"typescript.format.placeOpenBraceOnNewLineForFunctions": false,
"typescript.format.placeOpenBraceOnNewLineForControlBlocks": false,
"javascript.format.placeOpenBraceOnNewLineForFunctions": false,
"javascript.format.placeOpenBraceOnNewLineForControlBlocks": false
}
I don't find anywhere else I could set place new line to false.
Any idea how to set it right?
I notice this problem may resolve by changing the file extension when React component involved.
For example:
*.js -> *.jsx
*.ts -> *.tsx
Visual Studio Code seems to have trouble to format JSX when it's in the wrong type of file.
ESLint and "JavaScript and TypeScript intelliSense" extensions seems also don't like it.
Webpack works no matter what.
using SeedStack 14.7 we are facing a cache issue when uploading a new version on servers: every user have to clear their cache to get the last version of files.
I tried to use "urlArgs": "version=2" in the requireConfig part of the fragment JSON file. It do the job by adding argument on every files and so we can use it when changing version, but it also affect the urls in the config of each modules !
As we are using this config to pass the REST base url to each module, it breaks all REST requests by adding the argument to the base url.
My fragment JSON file :
{
"id": "mac2-portail",
"modules": {
"gestionImage": {
"path": "{mac2-portail}/modules/gestionImage",
"autoload": true,
"config": {
"apiUrl": "muserver/rest"
}
}
},
"i18n": {...},
"routes": {...},
"requireConfig": {
"urlArgs": "version=2",
"shim": {...}
}
}
Any idea to solve the cache issue without breaking REST requests ?
EDIT : it is not a duplicate of Prevent RequireJS from Caching Required Scripts. Yes SeedStack uses RequireJS and this configuration solve the cache issue, but it also affect other modules defined in the fragment so I need to find another solution to prevent browser to cache files
The module configuration values, like apiUrl in your example, are not touched by RequireJS unless you call require.toUrl() on them explicitly. I think this is what is happening in your case. To avoid this problem, you should always do the concatenation first and only then call require.toUrl() on the full resulting URL.
So, instead of doing:
var fullUrl = require.toUrl(config.apiUrl) + '/my/resource';
Do this:
var fullUrl = require.toUrl(config.apiUrl + '/my/resource');
By the way, instead of setting the version directly in the RequireJS configuration, you can simply add the version of your application to the data-w20-app-version attribute on the <html> element of the master page:
<html data-w20-app data-w20-app-version="2.0.0">
This will provide the same behavior but will work correctly in the case of Angular templates in $templateCache. If your master page is automatically generated by the backend, this is done automatically. Check this page for the details.
A complex qooxdoo (desktop) application may need to obtain deployment-specific configuration at startup, for example:
REST/WebSocket backend URL (which may be different from script/document location);
branding data;
enabled/disabled features;
performance tweaks
and so on. At the moment, we do the following:
<head>
<script type="text/javascript">
config = {
key1: "foo",
key2: "bar",
key3: "<%= getParameter("myapp.key3") %>"
};
</script>
<script type="text/javascript" src="script/myapp.js"></script>
</head>
As you've noticed, it's a JSP that provides dynamic config.key3, along with static config.key1 and config.key2. I somewhat dislike this approach because 1) config top-level object is not recognized in qooxdoo application code, and this results in compiler warning, 2) you can accidentally mess up with another top-level object of same name. Can anyone suggest any better, cleaner way to do the same? It's important that a combination of static and dynamic configuration is supported. For example, a developer hardcodes his specific config into some VCS-ignored JSON file; production environment serves config data from the database; staging/QA environment can use both sources for different parts of config.
The problem is not limited to qooxdoo, of course. I think this may as well be topical for any standalone JavaScript application that may need deployment-specific customization.
Use below method to solve both problems (warning and top level object):
a. in index.html before loading your application's JS:
window.qx = { $$environment: {
"myapp.key1": "foo"
} };
b. later in your Qooxdoo application
var key1 = qx.core.Environment.get("myapp.key1");
For pre-defined environments I suggest to use normal Qooxdoo configuration, not the hack #geonik presented. Here follows excerpt from normal config.json:
"config-warnings" :
{
"job-shadowing" : ["common", "source-script", "build-script"]
},
"jobs" :
{
"common" :
{
"environment" :
{
"appname.version" : "1.0.0",
"appname.timeout" : 30000,
"appname.analyticsId" : "UA..."
}
},
"source-script" :
{
"environment" :
{
"appname.serviceUrl" : "http://127.0.0.1:8080/service",
"appname.crossDomain" : true
}
},
"build-script" :
{
"environment" :
{
"appname.serviceUrl" : "/service",
"appname.crossDomain" : false
}
}
}
With the above you have one settings in development build and other settings in production build. You can add more environments, like QA. with other desired settings. Then access them with normal qx.core.Environment.get.
I don't suggest to mix runtime settings with Qooxdoo configuration which is inherently static. Just load them on application start with any qx.io.* way and handle in your classes.
This is currently possible:
ember build --environment=production
... and I would like to do something like this instead:
ember build --environment=production --baseurl=foo
but config/environment.js only gets passed in the value of environment.
Is it possible to get the value of the other options passed in at the command line too?
You could set environment variables the old fashioned way (export WHATEVER=wee) from terminal or as part of a build script, then reference them in your Brocfile.js via node with process.env.WHATEVER. After that, it would be a matter of having broccoli do whatever it is you needed to do with them. You could pre-process files and replace strings, for example.
... just a suggestion. Not sure if that's what you're looking for or not.
It appears that this is not allowed:
Looking in node_modules/ember-cli/lib/commands/build.js, we see:
availableOptions: [
{ name: 'environment', type: String, default: 'development' },
{ name: 'output-path', type: path, default: 'dist/' }
],
... and in node_modules/ember-cli/lib/models/command.js
this.availableOptions.forEach(function(option) {
knownOpts[option.name] = option.type;
});
... which together mean that any options that are not defined, for each subcommand of ember, get discarded.
You can do foo=bar ember build (however doing ember build foo=bar doesn't work)
And the argument is available via process.env.foo.
To extend upon #ben's answer.
The raw command line arguments are available inside ember-cli-build.js and other files from the
process.argv.[]
So a command like this
ember build staging
you can access via:
process.argv.includes('staging')
see node's documentation for whats available.
https://nodejs.org/docs/latest/api/process.html