Didn't see any definitive instructions for this on the web. I'm looking for a familiar way to include those modules in my project. For example by including them in the app.module.ts file and then importing them in the relevant components.
It Depends on the Place where the module is used. For Example if it is used in a particular module you can import that in respective module instead of doing that in app.module. This will eliminate the initial loading of the time and it will be much effective if you use lazy loading kind of things.
If that is used throughout the application you can create a shared module where you can import and export these type of third party and common components, directives etc.
Related
I wrote a package that uses pywin32 to sync GitLab issues with Microsoft Projects.
I would like to use readthedocs to host the documentation.
The problem is that I can't install pywin32 as a Linux environment is used there.
Any suggestion on how to get autodoc to build the documentation if a package is not available on the build machine?
The easiest way to solve this is setting autodoc_mock_imports = ["pywin32"]. This only requires setting the root package and any subsequent use your code makes of the library (calling or importing submodules, classes, etc) will be mocked by Sphinx.
Notice the mocked library won't provide any functionality besides allowing its components to be declared and importable. So your code should be structured to not have any module level execution depending on pywin32 callables, because the returns of those callbles will also be mocked.
I also found this guide that elaborates focused on ReadTheDocs builds and it suggests the same. Parallel to this problem I found the extension sphinxcontrib-mockautodoc that addresses the problem of making builds when you simultaneously have different Python versions in a given project.
I found a more or less ugly solution: Mocking the used modules and functions.
Needs quite some manual work.
Create a mocking folder in your project and create modules, classes and function stub for each class/function used.
After this edit the doc/conf.py and add:
try:
import win32com
except ImportError:
sys.path.insert(0, os.path.join(__location__, '../mocking'))
to automatically load the mocking if the real package is not available (and only then!).
Even so the solution is quite cumbersome it has one advantage. It allows for static typing, that would not be possible without.
Is it possible to modularize a node js application like namespacing in C# that when I import some namespace I do not have access to its internal members?
For example suppose I have three modules, module A, B, and C. Only module B uses module A export, so I want to package A and B and only export module B export.
If it's not possible, is there any transpiler, library or any other tool that can do it for me?
You need to change the architecture you are using. Check out Uncle Bob's clean architecture.
Check it out here:
http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
This architecture will allow you to write independent modules and just inject required modules anywhere as dependencies.
I'm writing a Node.js library that needs to import modules written by the user. If the user writes a module in Typescript he needs to transpile it into Javscript before feeds it into the library. I want to go one step further and make the library compatible with typescript modules in a transparent way. I can transpile the mdoule in os.tempdir(), read it into memory and delete it. It is a three step solution but i thought may be there is a more direct way.
I'm trying to figure out the best way to write a class library in Typescript and deploy it to NPM with a definitions file.
The classes in the library are essentially models that are shared across our various RESTful services. Some of them have a few utility functions.
In my current process, I've created a single module where all of the classes can be accessed from (index.js). And then I manually maintain a .d.ts that has all of the class and interface definitions. Any time I make a change to the actual implementation, I must remember to also update the definition file.
When I deploy to our private NPM server, I only deploy the the transpiled .js files and the definitions file. Services that install my npm package just need to add a single /// <reference path="..." /> to their references file.
This works; it's just cumbersome and error-prone. Is there a decent/easy way for me to generate a single definitions file automatically from all of the classes I have? If not, is there something different I can/should do to share common Typescript modules across projects?
All you have to do is add --declaration to your compiler options and it will create the corresponding d.ts file/s for you. No need to do that manually.
I have a question around the dependency injection based on AngularJS and NodeJS.
There's any difference between $injector from AngularJS and the require module from NodeJS?
Would be nice use require module with a MEAN STACK architecture instead $injector for the Angular app? And for whar propose?
They're quite different.
Angular's $injector is a classic example of Inversion of contorl. Instead of each module fetching their dependencies, you have an $injector whose job it is to provide dependencies to the modules that are asking for them at run-time. This makes it really to easy switch out the dependencies in tests for example, since nothing is forcing you to pass in the expected dependency -- you could pass in a mock version.
NodeJS's require methods just allow you to require other javascript files and have access to any properties they set on module.exports.
They're not mutually exclusive. You could use browserify (nodejs like require for the front-end) to load the different Angular modules if they are in separate files. It would essentially be equivalent to concatenating them, however. If you wanted to dynamically load the angular modules as needed, you would have to use something like RequireJs.
Conversely, you can use inversion of control in node by passing stuff into a module rather than trying to fetch it from the module. It's actually good practice in many cases.