I'm trying to set a global prefix for a dynamic module that I'm going to provide as npm dependency.
It works fine when I'm running the project as a stand alone app, but when I integrate the dependency in another Nestjs project, the prefix doesn't show as part of the url.
Any clue what is the reason of such behavior?
Also I tried to set the global prefix in the main project, but it was applied to all apis including those of the dynamic module.
Is there a way to set different global prefixes one for the dependency and another for the project using it?
Related
We are looking for a better way to swap out local modules via Terragrunt CLI. Currently engineers must comment out the module source (private git repo) and add a local path reference to their module. This is intrusive for many reasons, and has led to accidentally checking in the temporary pathing changes many times. Also, our TG project leverages module composition in both Root and Component modules. When working with a component module, this means we have 2 source references that need to be changed to test local module changes.
We've attempted to use --terragrunt-source and supplying the absolute path to the local module we would like to use, however, that does not work. When providing a path to local module for a component module, it results in variables being dropped and not getting passed from the root module (where we instantiate component module) to the component module.
This screenshot shows us trying to run live/dev/backends/app which instantiates the root module, tfm_10k_app module. The tfm_10k_app module instantiates the component module, tfm_10k_ecs_fargate. The tags are loaded from an external module git repo in the Root module, and passed as a variable to the Component module. However, the tags are not lost. It's not clear why when supplying the --terragrunt-source the tags are lost.
Would love some guidance around how to best leverage local modules for iterative development when adopting module composition best practices.
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.
so far i've learned a bit about NodeJS. But now i want to write a huge enterprise app with it and i'm wondering how to setup the structure correctly? Coming from other languages like PHP and Java, i imagine, i would split my project in different NPM modules. For example #mybigproject/customer, #mybigproject/cart and #mybigproject/checkout and so on.
But those submodules would be installed in the node_modules folder of the application skeleton. How would i tell for example Express, that the template files are in the different module directories? Or for example i use TypeORM for data access. So each module would have it's own set of models. How do those models know the database configuration data, as it's only in the main application skeleton, or the other way around, how does the application skeleton should know where to find the models?
Don't use npm modules for different parts of your project.
This components is integral part of your project and usually depend on your global config / schema / routing / etc
Just put it in different files and require it where you need it.
You can get an idea for folders structure from projects like Sail.JS
Use npm modules if you writing some utility that going to serve you for different apps and you want an easy way to upgrade the utility code once for all your apps (or in case you want to share that utility as open source for all of us)
NPM can install your local folder as a dependency. (ref)
npm install <folder>:
Install the package in the directory as a symlink in the current
project. Its dependencies will be installed before it's linked. If
sits inside the root of your project, its dependencies may be
hoisted to the toplevel node_modules as they would for other types of
dependencies.
Your module keeps its original location after installed and a symlink is created as the same name of your module folder in the top level node_modules folder.
In these custom sub-modules, you can use __dirname and relative paths to locate you configuration files to feed to database or other data consumers.
But remember that, sub-modules often serve as utility functions for the main module. They should be independent from the project context.
just like to add a short preface to this question - It may be a true issue of how Node functions, or it may be a fundamental misunderstanding on my part of how modules in Node work.
Recently, I've been working on a new project, specifically, a new Node module that requires some configuration via a .json file. I've had quite a few issues with this, being tested via linking the module to an Angular 2 (v5) project, and attempting to use the module in a service.
As I have the module set up right now, the configuration is loaded immediately as the module is initialized. It attempts to look for a config.json file, and read values from aforementioned file. I have this working, to an extent. I am able to require the file, read the file, and throw an error if the file is not found - but only in the same directory as the module's main file. The issue that I've come across is trying to determine how to find the path to the host project's root path - in this case, the Angular project. For example, say the absolute path to my module's root is /home/dev/angular2project/src/node_modules/module/. How can I determine the root path of the host, in this case /home/dev/angular2project/? What if the module has been installed globally?
I have attempted to use my weak understanding of the path module, paired with various searches of SO, to resolve this issue. I've tried using path.resolve(__dirname) to no avail path.resolve(process.cwd). This works well when debugging the module by itself. When attempted to be run from the Angular project, it simply returns / as the path, despite the actual root of the Angular project being home/dev/Desktop/angular2proj.
As the title suggests, i use browserify for my internal requires and on my node server that interferes with the require of global modules.
My solution now is to build the server script with browserify on the side, and then append a file that holds all my requires of global variables that are later gonna be used by the script. This renders browserify unable to try to put my global npm modules into my server script.
Is there a prettier solution to this? Because this way feels like a heap of dung.
-- EDIT --
The code runs only on backend, however - the problem is partially due to how i compile the code that is to be run on that backend. Initially the require keyword is used to get global node modules, e.g express or http. In my case, i need both that functionality as well as reference my own modules compiled with browserify.
My solution right now is to overwrite the global 'define' parameter with amdefine after i've saved references to the the global node modules that i will later use.
Code to bundle node modules into global parameters, require looks for global node modules
My Main, everything from this point forward, require looks for modules inside my own code
I guess I could make a duplicate of nodes require and make a new global reference to it, i.e, require becomes requireNodeModule, i feel as if that's an even worse solution to the one i have at present though...
It sounds like you have some code that runs both on the front-end and back-end, but at present this question is too broad for me to give you useful advice.
Can you narrow it down to a single, specific module that you want to run both in the browser and on your server, where the require clash is evident?