Develop Reference

How to deal with NestJS circular dependency when using dynamic modules

I'm trying to make a NestJS Library for an API I want to access. I split it off into its own library where the main module is a dynamic module that takes the baseUrl for the server it will be connecting to. I then have a second "child" api-section module that will actually be making the api calls. I need a way to pass that baseUrl into the api-section while also exporting the api-section service from the api-library to use in the main apps app.module. The modules are split this way since there will be many "child" modules to access different parts of the API as its very big.
Currently this leads to a circular dependency issue, with the cli suggesting I use a forwardRef. I've tried adding a forwardRef to both the ApiSectionModule import in ApiLibraryModule and vice versa but that leads to another error "TypeError: metatype is not a constructor"
I feel like this whole thing is just the wrong overall pattern, but not sure how else to approach it.
Sample repo:
https://github.com/computebender/libsample

Using stickit with Backbone in Webpack

I'm migrating my code from 'vanilla' to WebPack. Previously the backbone.js and backbone.stickit.js were loaded in index.html so that the code that was running later has seen stickit() function under Backbone.View.prototype (which is what my views extend from.
However, after migrating to WebPack I've started getting errors, that this.stickit() is not defined, which I've get rid of via adding the require to every JS file defining views extending from Backbone.View:
import Backbone from 'backbone';
require('backbone.stickit/backbone.stickit');
I don't feel good about that solution. In that specific case it is not so bad becasue my views explicitely use stickit. However, there are modules and extensions that alter the default behaviour, and I'd like to define them in one place.
How should I go about handling it? I've got a concept of importing Backbone, applying all plugins, and re-exporting it:
import Backbone from 'backbone';
require('backbone.stickit/backbone.stickit');
....
const Backbone2 = Backbone;
export {Backbone2};
which looks a bit too tricky...
How should I go about it? Shouldn't the webpack layer contain only one copy of Backbone after build, no matter in how many places it was imported, and which plugins were required?

Dynamic loading of modules and components at runtime in Angular 4

I've been looking to develop a method for loading modules and/or components into an AOT-compiled Angular 4 application and been stymied by a variety of solutions that never quite seem to get me where I want to be.
My requirements are as such:
My main application is AOT compiled, and has no knowledge of what it is loading until runtime, so I cannot specifically identify my dynamic module as an entry component at compile time (which is explicitly necessary for the 'dynamic' component loading example presented on Angular.io)
I'd ideally love to be able to pull the code from a back end database via a GET request, but I can survive it simply living in a folder alongside the compiled site.
I'm using Webpack to compile my main application, breaking it into chunks - and so a lot of the SystemJS based solutions seem like dead ends - based on my current research, I could be wrong about this.
I don't need to know or have access to any components of my main application directly - in essence, I'd be loading one angular app into another, with the dynamically loaded module only perhaps having a few tightly controlled explicit interface points with the parent application.
I've explored using tools like SystemJsNgModuleLoader - which seems to require that I have the Angular compiler present, which I'm happy to do if AOT somehow allowed me to include it even if I'm not using it elsewhere. I've also looked into directly compiling my dynamic module using ngc and loading the resulting ngfactory and compiled component/module, but I'm not clear if this is at all possible or if so - what tools Angular makes available to do so. I have also seen references to ANALYZE_FOR_ENTRY_COMPONENTS - but can't clearly dig up what the limitations of this are, as first analysis indicates its not quite what I'm looking for either.
I had assumed I might be able to define a common interface and then simply make a get request to bring my dynamic component into my application - but Angular seems painfully allergic to anything I try to do short of stepping outside of it alltogether and trying to attach non-angular code to the DOM directly.
Is what I'm trying to do even possible? Does Angular 2+ simply despise this kind of on the fly modification of its internal application architecture?

I think I found an article that describes exactly what you are trying to do. In short you need to take over the bootstrap lifecycle.
The magic is in this snippet here.
import {AComponentNgFactory, BComponentNgFactory} from './components.ngfactory.ts';
#NgModule({
imports: [BrowserModule],
declarations: [AComponent, BComponent]
})
export class AppModule {
ngDoBootstrap(app) {
fetch('url/to/fetch/component/name')
.then((name)=>{ this.bootstrapRootComponent(app, name)});
}
bootstrapRootComponent(app, name) {
const options = {
'a-comp': AComponentNgFactory,
'b-comp': BComponentNgFactory
};
https://blog.angularindepth.com/how-to-manually-bootstrap-an-angular-application-9a36ccf86429

dynamically load modules in Meteor node.js

I'm trying to load multiple modules on the fly via chokidar (watchdog) using Meteor 1.6 beta, however after doing extensive research on the matter I just can't seem to get it to work.
From what I gather require by design will not take in anything other than static strings, i.e.
require("test/string/here")
Since if I try:
var path = "test/string/here"
require(path)
I just get Error: Cannot find module, even though the strings are identical.
Now the thing is I'm uncertain how to go on about this, am I really forced to either use import or static strings when using meteor or is there some workaround this?
watchdog(cmddir, (dir) => {
match = "." + regex_cmd.exec(dir);
match = dir;
loader.emit("loadcommand", match)
});
loader.on('loadcommand', (file) => {
require(file);
});

There is something intrinsically weird in what you describe.
chokidar is used to watch actual files and folders.
But Meteor compiles and bundles your code, resulting in an app folder after build that is totally different from your project structure.
Although Meteor now supports dynamic imports, the mechanism is internal to Meteor and does not rely on your actual project files, but on Meteor built ones.
If you want to dynamically require files like in Node, including with dynamically generated module path, you should avoid import and require statements, which are automatically replaced by Meteor built-in import mechanism. Instead you would have to make up your own loading function, taking care of the fact that your app built folder is different from your project folder.
That may work for example if your server is watching files and/or folders in a static location, different from where your app will be running.
In the end, I feel this is a sort of XY problem: you have not described your objective in the first place, and the above issue is trying to solve a weird solution that does not seem to fit how Meteor works, hence which may not be the most appropriate solution for your implicit objective.

#Sashko does a great job of explaining Meteor's dynamic imports here. There are also docs
A dynamic import is a function that returns a promise instead of just importing statically at build time. Example:
import('./component').then((MyComponent) => {
render(MyComponent);
});
The promise runs once the module has been loaded. If you try to load the module repeatedly then it only gets loaded once and is immediately available on subsequent requests.
afaict you can use a variable for the string to import.

Use "require" in sails js app

When disabling globals the docs suggests using the following alternatives:
_ = require('lodash')
myService = sails.services.myservice
myModel = sails.models.mymodel
sails = req._sails
Would there be any issue requiring "sails", "services", and "models" much like any other module?
Having tried It, it does appear to work, however I feel I might be missing something.

Using require for services is always valid; the globalizing is merely for convenience.
On the other hand, doing require('api/models/User.js') will almost certainly not give you what you want, since those files are used by Sails to build model classes. So the only way to reliably use models in Sails without globals turned on is via sails.models.
Finally, while require('sails') will usually give you a reference to the running Sails app, it's not recommended that you use it that way. If you were running multiple Sails apps in the same process (which you might do in automated tests) then it would not reliably return the correct app. You're much better off using req._sails in controllers, and this.sails in models and services.