I have a composer package A and B. A is for non-Laravel projects, while B slightly extends A with some Laravel specific files (configs, facades, etc).
How should B require A? Would it be "^1.1" or "1.*"? As the minor version should not break anything, the second one may be better, as I would not have to update the composer.json of B that often.
Then, should B match the version of the Laravel framework (currently "5.6.x")? Is that good or bad practice? Some packages do it that way, other create separate branches for the different framework versions.
How should B require A? Would it be "^1.1" or "1.*"? As the minor version should not break anything, the second one may be better, as I would not have to update the composer.json of B that often.
That's entirely a policy decision on your part. It sounds like you control both A and B, so it should be easy for you to make the judgement whether A really adheres to Semantic Versioning or not, and the relative risks to B for taking every random minor bump from A.
Then, should B match the version of the Laravel framework (currently "5.6.x")? Is that good or bad practice? Some packages do it that way, other create separate branches for the different framework versions.
Never! You're not responsible for versioning Laravel, you are responsible for versioning B. B's dependency on Laravel is defined in the package definition. You will likely have the occasion to bump at least the patch level on B independently of its dependencies. If you need to make it obvious which Laravel version that B is intended for, you can include that at the package name level (B-Laravel.X.Y.Z BX.BY.BZ), the build meta data (B.X.Y.Z+Laravel.X.Y.Z) or even at the publish/feed level (seperate web pages, REST URI's).
My recommendation is for you to start at 1.y.z and follow the current SemVer spec.
See
GitHub:semver/semver/265
GitHub:semver/semver/352
GitHub:semver/semver/265
If both packages are yours and Private then you can Iclude it in composer.json
Here is an example.
"repositories": [
{
"type": "package",
"package":
{
"name": "adnanmayo/laralogs",
"version": "0.1.4",
"source": {
"url": "https://repo.url",
"type": "git",
"reference": "master"
}
}
}
],
You have to also create a auth.json file for credentials access.
{
"http-basic": {
"bitbucket.org": {
"username": "username",
"password": "Passwrod"
}
}
Hope this helps.
Related
We have stumbled across a bug that I can only assume is a bug with the JSON API code. This is for the old laravel JSON API (in my composer.json file its "cloudcreativity/laravel-json-api": "^2.0")
The issue is when a resource is included multiple times (in different ways), it is possible to not get all the include information you asked for.
In my example, I am dealing with timesheets. Timesheets belong to a user. They are also approved by a user. Those users are usually different users, but not always. If I want to include both, I would add include=user,approved-by, and this works great.
The front end also sometimes needs to know the employeeType of the user, so we instead use include=user.employee-type,approved-by, and again this works, we get the employee type info for the user. The issue arises when the user is the same as the approver. It appears that JSON-API gets the approved-by user (without the employee type include data), then when it tries to get the timesheet user, it sees that is has already grabbed that user, and just stops there.
The difference in the output is:
The include with the related in
"employeeType": {
"data": {
"type": "employee-types",
"id": "1"
},
"links": {
"self": "link url",
"related": "link url"
}
},
Vs the include without all the related info
"employeeType": {
"links": {
"self": "link url",
"related": "link url"
}
},
We have a work around, where we need to include the employee type of the user and a the approver, but that seems cumbersome and annoying.
I was wondering if anyone knows if there is any good fix for this? Or if this has been fixed in the more recent version (could be the kick in the pants we need to actually migrate to the most recent version of the library)
In polkadot-js has provided for developer to define custom types in the pallet, so that polkadot-ui can understand those types (it means can use some underlying API polkadot-js). These types are defined using the json format. This is example
{
"TransactionInput": {
"parent_output": "Hash",
"signature": "Signature"
},
"TransactionOutput": {
"value": "u128",
"pubkey": "Hash",
"sale": "u32"
},
"Transaction": {
"inputs": "Vec<TransactionInput>",
"outputs": "Vec<TransactionOutput>"
}
}
I see that in substrate-node-template/scripts has aggregrate_types.js file that generate types.json. I dont know how to generate it automaticly or I should write by hand.
Example that, in my pallet that i have defined enum RoleID and struct Role. But in UI it doesn't understand what RoleID is. Can you explain more clearly? I believe that it can be related to define types.json.
https://github.com/polkadot-js/apps/blob/master/packages/page-settings/src/md/basics.md#developer
aggregrate_types.json:
Thanks!!!
Presently, generating this by hand is the best way following the docs here. There are not clean ways to automatically generate this to my knowlage, but soon you will not need to worry about at all it once this PR lands in Substrate!
Thanks to https://github.com/paritytech/substrate/pull/8615, you don't have to manually write types.json anymore.
Make sure the metadata version of your node is v14 or higher. Otherwise you need to upgrade your substrate version to make it automagically work for you.
We are using the aurelia-cli for a single page application. It has the concept of multiple user modules (simple folders with view and view-models basically). Now as the application grows we want a way of not loading all modules up front. For example one user may only have access to 3 out of 20 modules.
Now the question is, how can we define bundles of modules and only load these on demand based on a condition at runtime?
We have managed to create bundles by editing the aurelia.json file. Our file looks like this for example
"bundles": [
{
"name": "my-module-bundle.js",
"source": [
"[**/my-module/*.js]",
"**/my-module/*.{css,html}"
]
},
{
"name": "app-bundle.js",
"source": [
"[**/*.js]",
"**/*.{css,html}"
]
},
...
This causes all the code for "my-module" to end up in its own bundle.
This also works in a sense that if no code has a reference to the "my-module" the bundle will not be downloaded and executed.
However... if we want to load this module dynamically based on a certain condition we are out of luck since we would need to reference the module thus causing it to download.
Is there any way around this problem? Can we for example load a bundle on demand using code?
As our team ( namely myself and two other developers ) spiked on PACT past week or so, one of the areas of concern is not having the ability associate parameters to provider states. The absence of this key feature ( which is slated for version 3 release ), we likely will not get buy in from each of our respective service sub-teams.
#MattFellows - Any projections on when version 3 might be available for Go? Any chance we can get this feature earlier?
Allow multiple provider states with parameters
In previous versions, provider states are defined as a descriptive string. There is no way to infer the data required for the state without encoding the values into the description.
{
"providerState": "an alligator with the given name Mary exists and the user Fred is logged in"
}
The change would be:
{
"providerStates": [
{
"name": "an alligator with the given name exists",
"params": {"name" : "Mary"}
}, {
"name": "the user is logged in",
"params" : { "username" : "Fred"}
}
]
}
You are correct in that it won't be available until version 3.
You can still achieve what you are after, however. The state itself is just a handle for the Consumer to some set of data on the Provider - that can be a one-to-one or one-to-many mapping - it's completely up to you.
Typically the Provider is notified of the state during verification, it will then setup a test data fixture (often seeding a database) that sets up the 'state' of the entire system based on that reference, which allows the Consumer test to run.
Whilst the ability to pass through parameters and multiple states is nice, it's somewhat an advanced feature and I very much doubt this will be the first problem you run into as a team. I've never needed to use them myself.
For a crude but effective example of this, take a look at the gin code in the examples folder of the project.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have a REST service I want to document for my client developing team.
So I added some Links from Spring-Hateoas to my resources API, and plugged into it swagger-springmvc #Api... annotations to document everything and make a good API reference for my Angular team to be able to understand my REST service.
The problem is that swagger is unable to discover what links are possible, and just give me a big array of Links without saying their possible values.
Here is a (simple) example. Swagger detects :
Model Schema
CollectionListResource {
collections (array[CollectionResource]): All available collections,
links (array[Link]): Relations for next actions
}
CollectionResource {
collectionId (string): Collection Unique Id,
name (string): Human readable collection name,
links (array[Link]): Relations for next actions
}
Link {
rel (string, optional),
templated (boolean, optional),
href (string, optional)
}
And I get in fact in HAL :
{"collections":
[{"collectionId":"5370a206b399c65f05a7c59e",
"name":"default",
"_links":{ [
"self":{
"href":"http://localhost:9080/collections/5370a206b399c65f05a7c59e"
},
"delete":{
"href":"http://localhost:9080/collections/5370a206b399c65f05a7c59e"
}
]}
}, ...]}
I've tried to extend Link and ResourceSupport to have annoted version of them but this lead me to nowhere.
Is there a way/tool I could use to generate a good API doc telling that a self relation is to get the content, and a delete relation is to delete the collection ?
I liked swagger for its good UI, but I don't mind changing my documentation tool if its help having the doc really complete.
I could eventually think of changing spring-hateoas for another link generator, but I'm not sure there is a better tool available right now.
Swagger-UI as such is not hypermedia aware; or atleast its limited in that it can ONLY navigate from top level apis to api listings. That has not changed much in v2.0 of the spec either, with the notable addition of linking to external documents for out of band documentation.
What you need is a hybrid of the HAL browser and the swagger-ui. As you rightly pointed out, there is a semantic gap between the word "delete" and what it means in the context of a collection resource. HAL uses a combination of curies and optionally a profile document ALPS to bridge this gap. Curies are nothing but namespaced versions of linked relations so that they dont collide with other domains. Restful Web APIs is a great resource to learn more about these ideas and how to design media types. The spring data rest project also has a great example of how to achieve that.
One of the ways that I think would work is to adjust swagger specification to support an operations oriented view rather than api listing oriented view, not really possible in the the timeframe that you're possibly working with.
Use existing RFC's like rfc5023 to have a shared understanding of what "edit"ing a resource means.
Lastly if none of the standard link relationships express the intent of the action, define your own application specific semantics that provide documentation for these application specific link relationships. That way clients of your service will have a shared understanding of these relations within the context of your application.
Below is an example that demonstrates and combines these approaches.
{"collections":
[{"collectionId":"5370a206b399c65f05a7c59e",
"name":"default",
"curies": [
{
"name": "sw",
"href": "http://swagger.io/rels/{rel}",
"templated": true
},
{
"name": "iana",
"href": "https://www.rfc-editor.org/rfc/rfc5023",
"templated": false
},
{
"name": "col",
"href": "http://localhost:9080/collections/{rel}",
"templated": false
}
],
"_links":{ [
"self":{
"href":"http://localhost:9080/collections/5370a206b399c65f05a7c59e"
},
"sw:operation":{
"href":"http://localhost:9080/api-docs/collections#delete"
},
"sw:operation":{
"href":"http://localhost:9080/api-docs/collections#search"
},
"sw:operation":{
"href":"http://localhost:9080/api-docs/collections#update"
},
"iana:edit":{
"href":"http://localhost:9080/collections/5370a206b399c65f05a7c59e"
},
"col:delete": {
"href":"http://localhost:9080/collections/5370a206b399c65f05a7c59e"
}
]}
}, ...]}
So from most generic to most specific, the solution (in that order) is
The iana qualified links have a specific meaning, in this case the "edit" has a very specific meaning that every restful client can implement. This is a generialized link type.
The sw qualified link relations have a special meaning as well, it implies the href deep links to operations in the swagger api documentation.
The col qualified links are application specific links that only your application knows about.
I know this doesn't answer your question precisely, and the tools in this space are still evolving. Hope this helps.
DISCLAIMER: I'm one of the core maintainers of springfox which is a spring integration solution that makes it easy to provide swagger service descriptions. So any feedback on how you'd like it to solve this problem is very welcome!