Get Packages composer.json Values Within Laravel Command Class - node.js

I would like to be able to set some configuration values within a particular package that I'm developing for laravel.
example:
"extra": {
"maxminddbpath": "src/storage/db"
},
I need to access those values from within one of my classes. How can this be accomplished.
Pseudocode might look something like this:
public function fire()
{
$this->getCompiler()->getPackage()->getExtra();//returns the extra node from composer.json
}
For my example I will be accessing the value from within a class that extends \Command
I would tend to agree that in some eyes this is something fanatical or silly because there is a better option. I understand that
In that case could you answer this, are there any instances where one might find it better as a software architect to locate provisional static values within that configuration file(composer.json)?
I think what is happening is we are avoiding the question by stating that it shouldn't be done.
an argument could then be made that the configuration of a json file is irrelevant to that of the application, which; by the nature the composer.json configuration file could not be true.
Take a look at this line of code on github:
https://github.com/mente/MaxMindGeoIpBundle/blob/master/Composer/ScriptHandler.php#L22
This was designed for symphony and not laravel but they are parent child branches of each other. I assume that there would be something within the laravel framework to handle this type of request.
Other uses might include:
Reading Grunt Files
Reading Ruby Configuration
Reading Node Configuration
Reading Deployment Settings
Reading Vagrant Configurations
Recommendations for a library?.

Configuration in composer.json should only be configuration which is used during a composer process. In such cases, you have to use composer scripts, which have access to this extras config.
When a setting is not specifically used in a composer process, it's more part of the app configuration and should belong in the configuration file of the application. I don't know Laravel well, but I guess it has nice configuration features.

Related

Monorepo Vue + Nestjs domain and platform object sharing

Objective:
Use a monorepo structure, in which I can share domain models and generic implementations (using a provider pattern) across the different Bounded Contexts
Ability to deploy each bounded context or client application independently of the others (thus all of this in a monolith under one src directory is not acceptable.
Background: Typical tech stacks for me is Angular + .Net Core. I am starting to move away from Angular and also exploring the code sharing benefits if I do my API development with Nestjs.
I am trying to figure out the best way to set up shared code between the client and API and running into some issues.
I have the following directory structure. I would like to figure out the best way to shared the models that are in the domain/models/comestibles in the api/comestibles and in the web application. I am ok with putting all of the shared code in a packages folder as well (was looking at Lerna)
I can easily point the code to the directory from the api/comestibles, but that is making the dist folder structure undesirable and also messing up things (like Swagger). I also had the change the outDir in the tsconfig.json from
"outDir": "./dist"
to
"outDir": "./dist/api/comestibles/src"
This broke other things in the application though as the directory structure is really altered.
I looked at setting up Bit and I have tracked some files, but I do not see any packages created for those files. Perhaps I am using it incorrectly though. I was also looking at Lerna for this. Given this is the first time I have done a full-stack application via scripting, I am unfamiliar with the best architecture for this solution.
Nx.dev plug-in solved my problem.
https://github.com/ZachJW34/nx-plus/tree/master/libs/vue

File specific TypeScript annotation for environment, like browser or node

I'm trying to write a universal React.js application using TypeScript and if possible it would like to somehow annotate certain TypeScript files in such a way that a file is understood to be running inside a browser context or Node.js context explicitly. So that any attempt to use browser APIs from within Node.js environment would fail, and vice versa. How can I do that?
Right now the files reside in the same directory and maybe that the problem because I cannot have multiple tsconfig files but if that is the only solution I guess I have to do it that way.
Each project described by a tsconfig.json file has a single set of visible declarations; there's no way to have different declarations visible in different files in the same project. You can put a <reference> directive in a specific file, but the directive will affect the entire project. So to enforce what you want using the regular type checker, you'll need to use multiple tsconfig.json files. There may be other approaches such as using the tslint "ban" rule to ban all APIs from one environment in a specific file, but I doubt they will be practical.

SSIS Shared database connection strings between parent and child packages

I want to be able to build 30+ packages in SSIS and be able to test/develop them in isolation. I also want to be able to run these from a Master/Parent package.
When it comes to delivering the SSIS parent package I want to be able to change the connection string once and have this trickle down to all child packages. Other developers will be building and testing without using the master package and want to be able to develop these in isolation.
I've seen many articles on XML config/parameter mappings etc. but I've not seen any definitive guide on how this should be done & what is best practice.
The project we have created also only allows packages to be linked in the solution as an external reference rather than as project links (is this the legacy format?). I'm wondering if this type of project could hamper the ability to achieve shared connection strings.
Answering this myself for reference. Basically there is no streamlined way of doing this in the Package Deployment model. It is much easier to achieve this using the Project Deployment model which is the default in VS2012. However, we don't have this luxury.
I had to create some parent variables contained in the master package. These are then set to the XML config. The child packages then have direct config links to the parent variables, with the target properties mapped to the connection string properties of the connection managers.

Can I change Angular-Fullstack's automatic naming conventions?

When I use generator-angular-fullstack's API to build routes, controllers, directives, whathaveyou, it appends naming conventions I don't like. For instance for all the module declarations it appends "App", and I'd prefer to not have "App" appended to my app name. Also, it uses "Ctrl" instead of "Controller", and so on.
I'm not seeing a json file that controls this behavior in my app or my angular-fullstack npm files. There's a good chance I'm overlooking something or not even looking in the right place.
Thanks!
You cannot edit the templates directly. You can either go back and rename them, or generate your own templates by replacing the routing through your .yo-rc.json file. It's located in the root folder of the project in all angular-fullstack apps unless removed.
It looks like angular-fullstack uses the generator-ng-component node module for the templates, here's a link to the github repo for controller template specifically. You could also make your own, fork it, then use it as your own generator.
https://github.com/DaftMonk/generator-ng-component/blob/master/templates/controller/name.controller.js

How should I structure my puppet configurations for shared environment resources (packages, configurations, etc) when using Puppet?

So I'm setting up puppet for a project I'm working on and I wanted to know what the best way to share resources between environments is. The problem is that I have a number of common packages that I want installed between a few different environments.
I read up on puppets support for environments and it looked like all you can do is specify the module path and the manifest. If that's the case, then what is even the point of environments?
What I'm thinking about doing is just having a shared module path that has a module with the shared packages to install and then importing that into each environment's site manifest, but that just seems like a hacky way of doing it especially when modules are supposed to be stand alone.
Is there a better way to implement this? Am I missing something?
Thanks.
You may use node to configure different environment:
# /etc/puppetlabs/puppet/manifests/site.pp
node 'dev' {
include common
include apache
include squid
}
node 'prod' {
include common
include mysql
}
Here's a reference: http://docs.puppetlabs.com/puppet/2.7/reference/lang_node_definitions.html

Resources