I'm building a custom blueprint for my organization's projects. Apparently, It's everything working fine.
I need to ask for a specific information to the blueprint user. So I've done in the PROMPTING priority, it works.
However, I want the user to be able to pass this info via command line parameter. So I thought that creating a custom parameter (option) would be a good idea, so I've done something like this:
export default class extends GeneratorBaseEntities {
constructor(args, opts, features) {
super(args, opts, { taskPrefix: PRIORITY_PREFIX, ...features });
this.option('parentProject', {
desc: 'Inform the parent project',
type: String,
});
...
Then I've executed the command line:
jhipster jdl --blueprints my-java-blueprint --parentProject MyParentProject --skip-install ~/myjdl.jdl
Then, I've got the following error:
INFO! No custom sharedOptions found within blueprint: generator-jhipster-my-java-blueprint at /home/.nvm/versions/node/v16.18.0/lib/node_modules/generator-jhipster-my-java-blueprint
(node:23361) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./lib/util/" in the "exports" field module resolution of the package at /home/.nvm/versions/node/v16.18.0/lib/node_modules/generator-jhipster/node_modules/yeoman-environment/package.json.
Update this package.json to use a subpath pattern like "./lib/util/*".
(Use `node --trace-deprecation ...` to show where the warning was created)
error: unknown option '--parentProject'
How could I create a new command line parameter for my custom blueprint?
I've also tried the following way in the constructor but the result is the same:
this.jhipsterOptions('parentProject', {
desc: 'Sigla do módulo SAD do qual os microsserviços farão parte',
type: String,
});
The problem was solved when I've created a new generator 'app', extending of AppGenerator class.
There, I've declared my option and it was recognized throughout the blueprint
export default class extends AppGenerator {
constructor(args, opts, features) {
super(args, opts, { taskPrefix: PRIORITY_PREFIX, ...features });
this.option('parent-project', {
desc: 'Inform the parent project',
type: String,
});
...
Related
I'm getting the following error when using nexus to define a graphql schema with apollo-server.
Error: NEXUS__UNKNOWN__TYPE was already defined and imported as a type
The stacktrace doesn't give much information as to where the issue is occurring or to what the problem is. The project has 20+ models and dozens of resolvers so it's quite hard to debug.
Error: NEXUS__UNKNOWN__TYPE was already defined and imported as a type, check the docs for extending types
at extendError (/Users/username/Documents/folder/folder/graphq-nexus-prisma-api/node_modules/nexus/src/builder.ts:1744:2)
at SchemaBuilder.addType (/Users/username/Documents/folder/folder/graphq-nexus-prisma-api/node_modules/nexus/src/builder.ts:603:8)
at SchemaBuilder.missingType (/Users/username/Documents/folder/folder/graphq-nexus-prisma-api/node_modules/nexus/src/builder.ts:1212:5)
at SchemaBuilder.getOrBuildType (/Users/username/Documents/folder/folder/graphq-nexus-prisma-api/node_modules/nexus/src/builder.ts:1540:4)
at SchemaBuilder.getOutputType (/Users/username/Documents/folder/folder/graphq-nexus-prisma-api/node_modules/nexus/src/builder.ts:1471:10)
at SchemaBuilder.buildOutputField (/Users/username/Documents/folder/folder/graphq-nexus-prisma-api/node_modules/nexus/src/builder.ts:1349:52)
at /Users/username/Documents/folder/folder/graphq-nexus-prisma-api/node_modules/nexus/src/builder.ts:1307:7
at Array.forEach (<anonymous>)
at SchemaBuilder.buildOutputFields (/Users/username/Documents/folder/folder/graphq-nexus-prisma-api/node_modules/nexus/src/builder.ts:1306:7)
at fields (/Users/username/Documents/folder/folder/graphq-nexus-prisma-api/node_modules/nexus/src/builder.ts:1009:33)
Any help appreciated.
I got the same error, but it was because I removed some exports. I'm not exactly sure what caused it, but I basically have a file that exports all of my graphql modules. E.g.
// graphql/modules/index.ts
export * from './file-a';
export * from './file-b';
When I removed the second export line, I started getting the error. I'm probably using some of the types defined in file-b somewhere else, and that's somehow causing the error. Anyway, adding the line back in fixed it (I had removed it by accident anyway).
UPDATE
I also go this by referencing some arg types that didn't exist (typo). For example:
args: {
where: arg({ type: 'ConversationsWhereInput' }),
orderBy: arg({ type: 'ConversationsOrderByInput', list: true }),
},
The s in Conversations shouldn't be there. It should be:
args: {
where: arg({ type: 'ConversationWhereInput' }),
orderBy: arg({ type: 'ConversationOrderByInput', list: true }),
},
It could have been much helpful if you could elaborate what did you do before this error happened.
I just came up with this error exactly as same as what you got and for me it was because I just accidentally changed the name for objectType of typeDef.
For instance, the name for the FollowUserResult was actually FollowResult and after I changed the name, the whole mutation resolvers related to this objectType became wrong.
export const FollowUserResult = objectType({
name: "FollowUserResult", // It was originally "FollowResult"
definition(t) {
t.nonNull.boolean("ok");
t.string("error");
},
});
You may check on this again. Once you got those correct, delete the schema.graphql file and generate the new schema.graphql file.
I got this error because I was using the incorrect Node version. My project didn't have a .nvrmc file (yet) so I was using Node 10 on a project that uses Node 14. So after switching to the correct Node version this error went away
I got this error when I incorrectly specified an unknown type in the type attribute of an extension to the Query type. More specifically:
export const CoursesQuery = extendType({
type: "Query",
definition(t) {
t.field("myQuery", {
type: InvalidType, // <--- Changing InvalidType to the correct type fixed the error
async resolve(_parent, _args, ctx) {
return ...
},
});
},
});
The error disappeared after I changed InvalidType to the correct type and restarted the server.
I'm currently struggling with making a Jest custom matcher work in VSCode with typescript.
I wrote a custom matchers file like the following (I've simplified the test for brevity reasons):
export {}
declare global {
namespace jest {
interface Matchers<R, T = {}> {
toSucceed(): R
}
}
}
function toSucceed(this: jest.MatcherContext, received: Result<any>): any {
return {
pass: true,
message: () => 'Custom matcher message',
}
}
expect.extend({
toSucceed,
})
I included this file path in my jest.config.ts under the tag setupFilesAfterEnv.
Then I wrote tests like:
it('should pass', () => {
expect(foo()).toSucced()
})
All this configuration works fine, but I still get a VSCode inline error:
Property 'toSucceed' does not exist on type 'JestMatchers<any>'
JestMatchers is a type definition inside the #types/jest root, since it is a type I cannot augment it directly.
Have anyone experienced any similar problem?
I encountered a similar error message when the namespace declaration of "interface Matchers" was incorrect. After fixing that, a custom matcher appeared in jestMatchers, too. Matchers and jestMatchers are connected.
Your code works fine for me—except for the undefined Result<any>—so you can try to directly import in test and see if Visual Studio Code can understand the declaration:
import "./toSucceed";
If direct import works for you, I would guess that there's a problem with the jest extension which helps Visual Studio Code understand jest.config.
Did you remember to add the type definitions to your tsconfig?
For me it works fine when I put the type definition in a d.ts file at the root level, and add that path to the "include" option in my tsconfig:
{
// Some other config
"include": [
"custom-matchers.d.ts"
]
}
Haven't tested with your custom matcher specifically, but I had a similar issue that I resolved like this.
So your custom-matchers.d.ts would be:
export {}
declare global {
namespace jest {
interface Matchers<R, T = {}> {
toSucceed(): R
}
}
}
I have a React.JS project which uses a custom 'theme' with UI components.
This theme also provides build scripts (webpack config, babel configs, etc.).
I want to start using Flow in this project.
I installed the needed npm packages and added flow to babel's presets, then I added props = {mytestprop: string} to one of my React` classes.
Webpack compiled my code successfully, but the type hints were not stripped! Of course, the browser was not able to execute this code - when I try to run it, it raisesReferenceError: string is not defined.
The current list of presets from .babelrc is: ["es2015", "react", "stage-2", "flow"]. I'm sure that this is the actual list used by babel because if I delete any of the first 3 presets, compilation fails.
Do you have any ideas on what could lead to this behavior when stripping Flow types?
It's not that type annotations are not being stripped. It's that { mytestprop: string } is not a valid type annotation on the right-hand side of an assignment because it clashes with the syntax for defining an object.
Specifically, when Flow's parser sees the statement { mytestprop: string } it will interpret this as an attempt to create an object with a field named mytestprop with its value set to the value of the variable string, so it will leave the statement alone as it is, and you'll get the error you've seen in the browser.
The correct way to type object declarations is to type the left-hand side of the declaration.
For instance,
let myProps: { myTestProp: string } = { myTestProp: "testProp" };
if you aren't declaring your props separately, you could declare a custom type:
type myPropType = { myTestProp: string }
// ...
const myComponent = (props: myPropType) => //render your component
Since the type statement is exclusive to Flow and not a valid JavaScript statement, it will be stripped correctly.
I'm trying webpack 2 code splitting.
According to this doc: https://webpack.js.org/guides/code-splitting-require/
the following code should include some.css into a new chunk named 'something'
require.ensure([], function(require) {
require('some.css');
}, 'something');
but when I run it, I get this error:
ERROR in ./src/index.ts
(4,9): error TS2339: Property 'ensure' does not exist on type 'NodeRequire'.
Any idea about how to fix it?
Thanks
The way I solved this was by creating my own interface - WebpackRequire - which extends NodeRequire with ensure1.
interface WebpackRequire extends NodeRequire {
ensure(
dependencies: string[],
callback: (require: WebpackRequire) => void,
errorCallback?: (error: Error) => void,
chunkName?: string
): void;
};
If you've only got a single instance of require.ensure, you can then type cast it to a WebpackRequire using (require as WebpackRequire).ensure, but since I used it multiple times in a module, I created local require at the top scope of the module, type cast as WebpackRequire, like this:
const require: WebpackRequire = (window as any).require;
1I got the types of ensure from the Webpack docs
I required a javascript document which then did the require. Not exactly the nicest solution, but it did work
I'm trying to create a custom user provider.
I defined my UserProvider as a service:
myvendor.user_provider:
class: MyVendor\UserBundle\Service\Security\UserProvider
This class is a DocumentRepository:
namespace MyVendor\UserBundle\Service\Security;
use Symfony\Component\Security\Core\User\UserInterface;
use Symfony\Component\Security\Core\User\UserProviderInterface;
use Symfony\Component\Security\Core\Exception\UsernameNotFoundException;
use Symfony\Component\Security\Core\Exception\UnsupportedUserException;
use Doctrine\ODM\MongoDB\DocumentRepository;
use Doctrine\ODM\MongoDB\DocumentNotFoundException;
class UserProvider extends DocumentRepository implements UserProviderInterface {
//public function loadUserBy...
}
But I get this error:
Catchable Fatal Error: Argument 1 passed to Doctrine\ODM\MongoDB\DocumentRepository::__construct() must be an instance of Doctrine\ODM\MongoDB\DocumentManager, none given, called in /home/www/dev/public/myapp/app/cache/dev/appDevDebugProjectContainer.php on line 258 and defined in /home/www/dev/public/myapp/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/DocumentRepository.php line 68
Seems like the document manager has not been created yet at that point, because I also tried injecting it, but it complains about its own dependencies, like the UnitOfWork.
What can I do?
The service definition was tricky
myvendor.user_provider:
class: MyVendor\UserBundle\Service\Security\UserProvider
factory_service: doctrine.odm.mongodb
factory_method: getRepository
arguments: [ 'MyVendorUserBundle:User\User' ]