Can anyone tell me what needs to be changed this test?
it('Should update settings of bar', () => {
const newSettings = {
dataset: [
{
data: [{
name: 'Category A',
value: 373,
color: '#1D5F8A',
id: 1
}],
name: ''
}
]
};
barObj.updated(newSettings);
const dataLength = barObj.settings.dataset[0].data.length;
expect(dataLength).toEqual(1);
});
I am getting this error from Jasmine and if i follow the link https://jasmine.github.io/tutorials/upgrading_to_Jasmine_4.0#matchers-cet i dont see exactly what i would need to change?
ERROR: 'DEPRECATION: The matcher factory for "toHaveBeenTriggeredOnAndWith" accepts custom equality testers, but this parameter will no longer be passed in a future release. See https://jasmine.github.io/tutorials/upgrading_to_Jasmine_4.0#matchers-cet for details. (in spec: Bar API Should update settings of bar)
I also cant find a lot of information about this message. I also dont have any custom equality matchers in the system. https://jasmine.github.io/tutorials/custom_equality
Try to update karma-jasmine package. It helped me.
I had this problem using "#metahub/karma-jasmine-jquery". You can modify the bundle in place and remove the second parameter from the `` toHaveBeenTriggeredOnAndWith" function. Or copy the module somewhere, uninstall "#metahub/karma-jasmine-jquery" and install the modified module: npm install ./#metahub/karma-jasmine-jquery
Related
I'm trying to set up a simple Batch Compute Environment using a LaunchTemplate, so that I can specify a larger-than-default volume size:
const templateName = 'my-template'
const jobLaunchTemplate = new ec2.LaunchTemplate(stack, 'Template', {
launchTemplateName: templateName,
blockDevices: [ ..vol config .. ]
})
const computeEnv = new batch.CfnComputeEnvironment(stack, 'CompEnvironment', {
type: 'managed',
computeResources: {
instanceRole: jobRole.roleName,
instanceTypes: [
InstanceType.of(InstanceClass.C4, InstanceSize.LARGE).toString()
],
maxvCpus: 64,
minvCpus: 0,
desiredvCpus: 0,
subnets: vpc.publicSubnets.map(sn => sn.subnetId),
securityGroupIds: [vpc.vpcDefaultSecurityGroup],
type: 'EC2',
launchTemplate: {
launchTemplateName: templateName,
}
},
})
They both initialize fine when not linked, however as soon as the launchTemplate block is added to the compute environment, I get the following error:
Error: Resource handler returned message: "Resource of type 'AWS::Batch::ComputeEnvironment' with identifier 'compute-env-arn' did not stabilize." (RequestToken: token, HandlerErrorCode: NotStabilized)
Any suggestions are greatly appreciated, thanks in advance!
For anyone running into this - check the resource that is being created in the AWS Console - i.e go to aws.amazon.com and refresh the page over and over until you see it created by CF. This gave me a different error message regarding the instance profile not existing (A bit more helpful than the terminal error...)
A simple CfnInstanceProfile did the trick:
new iam.CfnInstanceProfile(stack, "batchInstanceProfile", {
instanceProfileName: jobRole.roleName,
roles: [jobRole.roleName],
});
I faced similar error.
But in my case cdk had created subnetGroups list in cdk.context.json and was trying to use the same in the CfnComputeEnvironment definition.
The problem was; I was using the default vpc and had manually modified few subnets. and cdk.context.json was not updated.
Solved by deleting the cdk.context.json
This file was recreated with correct values in next synth.
Tip for others facing similar problem:
Don't just rely on the error message; watch closely the Cloud-formation Script that's generated from CDK for the resource.
I'm using Cypress and upgraded to version to v8.3.1 and a new error keeps showing up.
Cannot read property 'duration' of undefined
Because this error occurred during a after all hook we are skipping all of the remaining tests.
Location: node_modules/#cypress/code-coverage/support.jsat line210
cy.task('coverageReport', null, {
timeout: Cypress.moment.duration(3, 'minutes').asMilliseconds(),
^
log: false
})
It says that duration cannot be found since Cypress.moment doesn't exist.
I checked the changelog and they removed it:
Cypress.moment() has been removed. Please migrate to a different datetime formatter. See our recipe for example replacements. Addresses #8714.
But since I'm not directly using it, it's in the code coverage included in Cypress, I don't know how to fix it.
Somehow you've obtained an old version of #cypress/code-coverage.
Perhaps you upgraded Cypress and not the code-coverage package?
#cypress/code-coverage#3.2.0 - support.js
after(function generateReport() {
// when all tests finish, lets generate the coverage report
cy.task('coverageReport', {
timeout: Cypress.moment.duration(3, 'minutes').asMilliseconds()
})
})
#cypress/code-coverage#3.9.10 - support.js
after(function generateReport() {
...
cy.task('coverageReport', null, {
timeout: dayjs.duration(3, 'minutes').asMilliseconds(),
log: false
}).then((coverageReportFolder) => {
...
})
npm update #cypress/code-coverage should fix it
I am trying to follow the documentation on the Nexus-Schema (nexusjs) website for adding scalar types to my GraphQL application.
I have tried adding many of the different implementations to my src/types/Types.ts file using the samples provided in the documentation and the interactive examples. My attempts include:
Without a 3rd party libraries:
const DateScalar = scalarType({
name: 'Date',
asNexusMethod: 'date',
description: 'Date custom scalar type',
parseValue(value) {
return new Date(value)
},
serialize(value) {
return value.getTime()
},
parseLiteral(ast) {
if (ast.kind === Kind.INT) {
return new Date(ast.value)
}
return null
},
})
With graphql-iso-date 3rd party library:
import { GraphQLDate } from 'graphql-iso-date'
export const DateTime = GraphQLDate
With graphql-scalars 3rd party library (as shown in the ghost example):
export const GQLDate = decorateType(GraphQLDate, {
rootTyping: 'Date',
asNexusMethod: 'date',
})
I am using this new scalar type in an object definition like the following:
const SomeObject = objectType({
name: 'SomeObject',
definition(t) {
t.date('createdAt') // t.date() is supposed to be available because of `asNexusMethod`
},
})
In all cases, these types are exported from the types file and imported into the makeSchema's types property.
import * as types from './types/Types'
console.log("Found types", types)
export const apollo = new ApolloServer({
schema: makeSchema({
types,
...
context:()=>(
...
})
})
The console.log statement above does show that consts declared in the types file are in scope:
Found types {
GQLDate: Date,
...
}
If I run the app in development mode, everything boots up and runs fine.
ts-node-dev --transpile-only ./src/app.ts
However, I encounter errors whenever I try to compile the app to deploy to a server
ts-node ./src/app.ts && tsc
Note: This error occurs occurs running just ts-node ./src/app.ts before it gets to tsc
The errors that shown during the build process are the following:
/Users/user/checkouts/project/node_modules/ts-node/src/index.ts:500
return new TSError(diagnosticText, diagnosticCodes)
^
TSError: тип Unable to compile TypeScript:
src/types/SomeObject.ts:11:7 - error TS2339: Property 'date' does not exist on type 'ObjectDefinitionBlock<"SomeObject">'.
11 t.date('createdAt')
Does anyone have any ideas on either:
a) How can I work around this error? While long-term solutions are ideal, temporary solutions would also be appreciated.
b) Any steps I could follow to debug this error? Or ideas on how get additional information to assist with debugging?
Any assistance would be very much welcomed. Thanks!
The issue seems to be resolved when --transpile-only flag is added to the nexus:reflect command.
This means the reflection command gets updated to:
ts-node --transpile-only ./src/app.ts
and the build comand gets updated to:
env-cmd -f ./config/.env ts-node --transpile-only ./src/app.ts --nexusTypegen && tsc
A github issue has also been created which can be reviewed here: https://github.com/graphql-nexus/schema/issues/690
Does anyone know npm yargs very well? I am using this package for command line argument thing.. BUT I cannot find explanation for "builder". Where can i get this?
yargs.command({
command: 'test',
describe: 'testing a note',
builder:{
sample:{
describe: 'Note content',
demandOption: true,
type: 'string'
},
},
handler(argv){
notes.addNote(argv.title, argv.content);
}
})
The builder pattern can help with giving more context with documentation help messages on using multiple commands that can be used.
We would normally use the lambda function version rather than the object version.
For an example, one application can support a number of "commands". These commands would have different bits of functionality associated with the same application.
Below is a simple get/post example that the user can do:
$ node src/index.js get
$ node src/index.js post "" 5001
The get and post after index.js is what yargs considers commands.
One way you could implement this in yargs is:
require('yargs') // eslint-disable-line
.command('post data [port]', 'post some data', yargs => {
yargs.positional('data', {
describe: 'post string',
require: true
})
.positional('port', {
require: false,
describe: 'port to bind on',
default: 8080
})
})
.command('get [port]', 'get some data', yargs => {
yargs.positional('port', {
require: false,
describe: 'port to bind on',
default: 8080
})
})
.option('verbose', {
alias: 'v',
type: 'boolean',
description: 'Run with verbose logging'
})
.argv
So when requesting help information, you can do the following:
$ node src/index.js --help
index.js [command]
Commands:
index.js serve [port] start the server
index.js post data [port] post some data
Options:
--help Show help [boolean]
--version Show version number [boolean]
-v, --verbose Run with verbose logging [boolean]
You can then drill into the help information further:
$ node src/index.js post --help
index.js post data [port]
post some data
Positionals:
data post string [required]
port port to bind on [default: 8080]
This shows the specific help for the post command.
Hence, the command builder pattern allows us to pass any number of commands to an application and provide argument documentation thereof.
It's quite useful when you have to support a number of disparate commands that need their own arguments.
So a long way round to answer the question on where to get more documentation is that if you use the lambda version, the yargs main object is passed to you and you can use all the usual yargs parameters to describe your parameters per command.
Hence, in the example above, the usage of yargs like:
yargs.positional('port', {
require: false,
describe: 'port to bind on',
default: 8080
})
is documented at:
https://github.com/yargs/yargs/blob/master/docs/api.md
I found the above answer a bit complicated and to help anyone who may land on this page in the future, I would recommend reading this GeeksForGeeks article:
https://www.geeksforgeeks.org/node-js-yargs-module/
The example with .command(cmd, desc, [builder], [handler]) is this:
//Add note
yargs
.command({
command: "add",
describe: "Add a note",
builder: {
title: {
describe: "Title of the note",
demandOption: true,
type: "string",
},
},
handler: (argv) => {
console.log("Added note with title:", argv.title);
},
})
.parse();
In the terminal, you have to type:
node app.js add --title="The Complete Node.js Developer Course (3rd Edition)"
Webpack has a resolve.mainFields configuration: https://webpack.js.org/configuration/resolve/#resolvemainfields
This allows control over what package.json field should be used as an entrypoint.
I have an app that pulls in dozens of different 3rd party packages. The use case is that I want to specify what field to use depending on the name of the package. Example:
For package foo use the main field in node_modules/foo/package.json
For package bar use the module field in node_modules/bar/package.json
Certain packages I'm relying on are not bundled in a correct manner, the code that the module field is pointing to does not follow these rules: https://github.com/dherman/defense-of-dot-js/blob/master/proposal.md This causes the app to break if I wholesale change the webpack configuration to:
resolve: {
mainFields: ['module']
}
The mainFields has to be set to main to currently get the app to work. This causes it to always pull in the CommonJS version of every dependency and miss out on treeshaking. Hoping to do something like this:
resolve: {
foo: {
mainFields: ['main']
},
bar: {
mainFields: ['module'],
}
Package foo gets bundled into my app via its main field and package bar gets bundled in via its module field. I realize the benefits of treeshaking with the bar package, and I don't break the app with foo package (has a module field that is not proper module syntax).
One way to achieve this would be instead of using resolve.mainFields you can make use of resolve.plugins option and write your own custom resolver see https://stackoverflow.com/a/29859165/6455628 because by using your custom resolver you can programmatically resolve different path for different modules
I am copy pasting the Ricardo Stuven's Answer here
Yes, it's possible. To avoid ambiguity and for easier implementation,
we'll use a prefix hash symbol as marker of your convention:
require("#./components/SettingsPanel");
Then add this to your configuration file (of course, you can refactor
it later):
var webpack = require('webpack');
var path = require('path');
var MyConventionResolver = {
apply: function(resolver) {
resolver.plugin('module', function(request, callback) {
if (request.request[0] === '#') {
var req = request.request.substr(1);
var obj = {
path: request.path,
request: req + '/' + path.basename(req) + '.js',
query: request.query,
directory: request.directory
};
this.doResolve(['file'], obj, callback);
}
else {
callback();
}
});
}
};
module.exports = {
resolve: {
plugins: [
MyConventionResolver
]
}
// ...
};
resolve.mainFields not work in my case, but resolve.aliasFields works.
More details in https://stackoverflow.com/a/71555568/7534433