I'm working on a library that lets users run Node processes from inside another application. The library is called "max-api"; functions for sending data to the host application are exposed through a Node module and are loaded in the expected way:
const maxAPI = require("max-api");
However, the user never interacts with this module directly. Rather, when the host application launches the Node process, it intercepts the call to require, checks if the name of the module is "max-api", and provides the module if so.
This works great, the only issue is we have no way to provide type definitions for this modules. So, the user doesn't get any autocomplete or validation for functions in the "max-api" module. I was thinking of writing a VSCode extension to provide these, but I'm not 100% sure how to get started. Thanks in advance for any advice.
You could write a TS typings file (see Definitely Typed). This would be installed in node_modules/#types and vscode will automatically pick it up to provide code completion for your module.
Related
I want to create a custom powershell module that I can distribute without exposing the code. The script includes API calls with app specific private keys that I don't want to compromise. I've seen a lot of discussions about this over the years, but nothing that really solves my problem.
Is there a good way to create a custom powershell module without exposing the underlying code? I want to be able to distribute the powershell module, for others to import or install.
this may be what you are looking for : https://www.powershellgallery.com/packages/ps2exe/1.0.11
but be careful, the API key will still be in the compiled file at someplace. You can try and cipher it, but if it's needed for your script, it will be in your file no matter how you try to hide it. the question is why do you need to ship it inside your script in the first place ? I mean that any of your script's user will be using your private key which is likely not what you want to do
What I'm trying to do in Aurelia, is something like Prism is doing in WPF- Composite applications.
So lets say I have a "shell" application that defines the main application layout, then i have modules that I can plugin at run-time. Those modules can be an Aurelia application per se or Aurelia plugin (don't know what to use - need recommendation).
When loaded, the module needs to add it's menu items to the main application menu to expose it's features.
This is a mockup of the application:
Each module can have multiple menu items and can be pretty complex.
I'm using latest Typescript, Aurelia-CLI to create the application, and I'm using the built-in bundler : Aurelia's new built-in bundler.
So What I don't know is:
Those modules/features - what must they be? (Maybe Aurelia Plugins, or another Aurelia application?)
How to load those modules/features at run-time? (like deploy it in some plugins folder and tell the main shell application to load them)
How to modify the main menu and add new menu items from the loaded module?
Please help
Aurelia supports ultra dynamic applications. Also, there have been other community members who have had similar requirements and was able to resolve it. So I think the scenario is possible.
It seems the sub-application can just be a route.How/where to load the route should be determined based on the application URL
Those modules doesn't need to do anything specific, they can just be a normal, plain JS/TS class with lifecycle methods to handle activation/deactivation. I guess that main shell and all sub-applications need to share a common URL, you cannot have more than one router.
There could be a singleton/central store for new route to register information about loaded features, or it can be loaded upfront by a configuration file/metadata file or a database fetch.
Here is a similar question from another community member that I think can help you see how to glue things to https://discourse.aurelia.io/t/dynamicaly-load-routes/1906
I am currently writing a Powershell module that I can use to control some smart light bulbs. A requirement for the API is that I provide an authorization token with each request. I currently have a cmdlet Set-AuthorizationToken that sets a $Script: scoped variable to store this token.
Currently all of the setting functionality I have created exists in the same light automation module. I would like to separate the settings logic into its own module so it can be reused.
This is where I run into trouble. To my knowledge, if I pull the settings logic into its own module then I would no longer be able to use the $Script: scope as that would be shared with any module that consumes the settings module. Additionally I would have to refactor the current settings functionality to some provide some sort of identifier so the settings module can look up the correct settings for the caller.
Is there some way that I can create the settings module so I can reuse it, but maybe load it in a manner that allows it to only know about the module that loads it? Maybe like a "library" of some sort? I would prefer not to copy the ps1 files into each module but currently that seems like the best way.
The typical way to handle this seems to be to store your credentials as an encrypted string in a file and then have a function for loading those credentials.
For example: https://github.com/RamblingCookieMonster/PSSlack/blob/master/PSSlack/Public/Get-PSSlackConfig.ps1
I have created two separate add ons. One for getting input from the user and storing in simple-storage. In the other one the actual add on function. Both work fine. But when i merge these both main add on code in to a single main code they didn't work. So i wonder whether there can be two js files in "main" add on directory and is communication possible between them?I need one of the js in main directory to be able to access the simple-storage of the other js in the same main directory.
I'm really not sure what your overall goal is, please provide an example for a more specific answer. If you're using the Add-on SDK, only code in main.js will be run, but you can use commonJS modules to implement various features and use require to import them into main.js.
Please see the docs for more information on how the Add-on SDK works:
https://developer.mozilla.org/en-US/Add-ons/SDK
I have a Qt application containing a Webkit module and using Dart (compiled to JS). It's like a bare-bones browser written in Qt. The application basically replaces certain text on the webpage with different text. I want users to be able to make their own Dart files to replace their own text with their own different text.
Any recommendations for approaches to creating a plugin system?
I think that this question needs a little clarification: are you asking about using Dart for scripting Qt applications (where Dart plays the role of a scripting language), or are you asking about a plugin system for Dart application that is compiled to JS and used in a Qt application, probably via QtScript (in which case, the role of a scripting language is played by JavaScript)?
I presume that it is the latter variant (and I don't know enough about Qt to be able to answer about the former variant anyway).
Let's assume that all plugins for the Dart application are available at the build time of that Qt application, so that you don't need to compile Dart to JS dynamically. Then, if you compile a Dart script, resulting JS will include all necessary code from its #imports. All you need is to create a proper script that imports all plugins and calls them (importing isn't enough, as dead code will be eliminated).
Maybe an example will be more instructive. Let's say that you want to allow plugins to do some work on a web page. One way you might structure it is that every plugin will be a separate #library with a top-level function of a well known name (say doWork). Example of a plugin:
// my_awesome_plugin.dart
#library('My Awesome Plugin')
doWork(page) {
page.replaceAll('JavaScript is great', 'Dart is great');
}
You can have as many plugins of this nature as you wish. Then, you would (at the build time) generate a following simple main script in Dart:
// main.dart
// these lines are automatically generated -- for each plugin file,
// one #import with unique prefix
#import('my_awesome_plugin.dart', prefix: 'plugin1');
#import('another_plugin.dart', prefix: 'plugin2');
main() {
var page = ...; // provided externally, from your Qt app
// and these lines are automatically generated too -- for each plugin,
// call the doWork function (via the prefix)
plugin1.doWork(page);
plugin2.doWork(page);
}
Then, if you compile main.dart to JavaScript, it will include all those plugins.
There are other possibilities to structure the plugin system: each plugin could be a class implementing a specific interface (or inheriting from a specific base class), but the general approach would be the same. At least the approach that I would recommend -- making each plugin a separate library.
You probably don't like the step with generating the main script automatically, and I don't like it either. But currently, Dart only allows one way to dynamically load new code: spawning new isolates. I'm not sure how (or even if) that would work in QtScript, because isolates are implemented as web workers when compiled to JavaScript, so I won't discuss this here.
Things will get more complicated if you want to support compiling Dart scripts at the runtime of your Qt application, but I think that I'm already guessing too much about your project and I might be writing about something you don't really need. So I'll finish it like this for now.