I am developing a NodeJS application, and was thinking about the best way to develop a plugin system. Currently, most components on the application are already decoupled in a way that they can be registered in and out to add and/or remove functionality. But currently, those components are still spread across many folders inside the app source. My goal would be to have a plugins folder, with a sub-folder for each plugin, and the application would scan said folder on startup to load the plugins. Also, as a nice plus, I'd love to load plugins from the node_modules (inspired by the way babel handles presets in version 6). I already have a fairly good idea how this system will work.
Now, my question is what is the best way to provide access to common files and classes, to the plugins. Let's say that I have a base class Receiver, and a plugin registers a custom receiver (which will extend the base class Receiver). How do I provide access for all theose classes to an external npm module without creating an object and passing each manually?
I use ES6 imports which replace the node's require function in my code, and use relative paths, but to be honest, I've never really understood how babel implements these module loaders and how could I use a dynamic module loader.
Related
I have been looking for a way to mostly share some code between projects specifically for SPFX and fluent ui. We found 3 main ways to do that.
1.
Creating a component library is the way that seemed least complicated cause it uses the same infrastructure and do all building without the need to configure it.
But this adds some issues, we need to built and manually link the solution locally to make it work, this will also work if we put in a repo. so this is mitigated.
The second is that implicitly this will also require the fluent ui and react. Plus having to place it inside a SPFX component library project.
2.
I saw some promise using paths in ts and this works fine while using the ts compiler. It will go to the folder that your proj is referring and build it at calling time. which is great. But it did not work in SPFX.
3.
Another way was to have a post install to sync the folders which seems easy enough but I wonder how practical this is plus how people are doing it, if they are, how.
All I wanted to figure out now is a way to take my component code and share as if they were in a folder of my src or a simple extension of the code. No need to have extra dependencies or build steps, just the code that can be used as a ts/tsx file. ex:
shared lib:
//assuming I have react and fluentui already installed for the project.
import button from 'fluentui';
export const fancyCustomButtom = (props) => {
return (<Button text="Standard" />);
};
src project folder:
import {fancyCustomButtom} from 'shared-lib'
It is fine if it needs to build the files before we can use it but can we do it at build time or when the package is installed? also wouldn't it increase my bundle size by making both module dependent on things already available (react, fluentui)?
Given the way Microsoft have architected the loading of bundles in SharePoint and Teams - I believe an SPFX component library is the best way to share code between different solutions, particularly if you are looking to minimise bundle size...
Imagine you have a library for something re-usable: a form, a set of standard branded components - something of that nature. You could put your shared code in repos and add references to it - either by publishing your own repo publicly or using the npm install git+https://yourUrl syntax; but what effectively happens there is that your code is pulled down in to node_modules for each project, and any referenced module code is included in your bundles. If you have two, three, four or more webparts on the same page - using those same libraries, you're multiplying how many times that code is included on the page.
If you follow Microsoft's guide on setting up a component library project however, your npm link commands allow your types to be recognised in consuming projects without needing to actually include the bundled distribution code. You can deploy your library code once to the App Catalog, and if it's referenced in other solutions -- it's loaded on pages as needed: once.
I have found the development experience to be quite flaky at times, but it does work. When I run gulp clean on my library code, or come back to it after some time, I sometimes find that I need to run npm link and npm link my-project-name again as per the instructions in the above tutorial. Whenever you run gulp build on your library, you should also rebuild the project that consumes the library, either by using gulp build / bundle or by saving a file (if you're running gulp serve). This process works well for developing, and once it comes time to deploy, all you need to do is add a named reference to your library inside package.json and then deploy both .sppkg files to your App Catalog.
In terms of your last question re: bundle size - react is not actually included in the dependencies for an SPFX library project, but you will find it's available to use. When you build your library, if you take a look in the generated javascript in your dist folder, you will see it's listed as one of the dependencies for the webpacked content along with react-dom and ControlStrings. It's on line 1.
office-ui-fabric-react is included as a devDependency thanks to the #microsoft/sp-webpart-workbench package that gets scaffolded with all SPFX projects - and if you check your library's dist javascript, you will see that included components are being webpacked and included in your bundle. I'm not entirely sure if when you pull this code in to your consuming project, whether webpack then tree-shakes to de-duplicate and ensures only necessary code is included: I don't know. Someone else may be able to illuminate us there or provide a more accurate explanation of what's going on... I will update this response if anyone comments to let me know.
And finally, this is more of a personal way of working, but it may be worth consideration:
When developing a library, I sometimes reference it in other projects via a local npm install ../filepath command. This ensures that when I install the library as described, the consuming project installs any necessary dependencies. I'm able to tweak both projects if I need o. When it comes time to deploy, I commit my changes to both projects, deploy my library code to the App Catalog, and then npm uninstall the library from the consuming project and add a reference as described in the above tutorial. When I deploy projects that use my library, they just work.
I recently developed a library that uses pnpjs, in particular the #pnp/sp library that is used to talk to SharePoint. If you look at the Getting Started guide for that library, they expect you to pass a reference to your Application Customizer or Web Part context during setup, or explicitly set things up using a base URL and so forth - and of course, a library doesn't really have a page context of any sort - the whole point of this code is that it's reusable. So that poses a challenge. My solution was to do the setup in the consuming web part(s) and ensure that they pass a reference to the sp object (which is of type SPRest) to any code or components that exist in my library. My library has peerDependencies on those pnp libraries so that the code isn't duplicated in consuming projects. Sometimes you have to think about what your library needs to include in its bundle and what you expect consuming solutions to already have, and maybe find ways to ensure things aren't included that aren't needed.
For example, in the scenario you talk about, you may want to ensure fluentui or office-ui-fabric-react are only devDependencies or peerDependencies for your library. As long as your library and the project(s) consuming your library both use the right version(s) you shouldn't have any trouble, and you can document any pre-requisites with your library documentation. You can check which versions of these libraries are installed per the SPFX version you are currently using ie. SPFX v1.11 or v1.12 etc. Just run npm ls <packagename> to get a breakdown, or check your package.json file.
This is my problem: I created a library to use within Chrome extensions. This library exports two classes, one of which should be imported in the background script and one in the content scripts.
The background script (and other scripts that are used in the extension pages) can handle modules, so I would like to use the native "import"/"export" feature of ES6 Modules.
The content scripts do not support modules. That means that if I use the "export" keyword in my library script, that will throw an error, and I won't be able to use the library anymore.
Currently, I'm not implementing modules at all, and that solves the problem, but I would like to implement this functionality, so that it can be used when someone has access to it.
Is there a way to offer my library functionality as both a module and a non-module for both kind of scripts? Is that actually something that I should do?
In the end, I set up two git branches:
1 - In the first one, I just kept the file without the "export", so no ES6 modules capabilities
2 - This other branch, I decided to set it up to be published on NPM, and in this one I exported my classes. If you use NPM for your development, it's already very probable that you also have a bundler like webpack to keep track of modules and dependencies.
Whenever I do a change, I do it in the master (no exports) branch, and then I merge the changes in the npm branch, to avoid writing the same code twice
Basically I have a number of legacy web applications that reference and use a library from a CDN (Kendo UI). I have a task to remove such requests to remote hosts and so I'd like to encorporate the library into an existing npm script task that collects all dependencies into a single local js file which the application references.
The problem I'm having is that this library does not provide pre-compiled js files that can be used immediately (unlike other libraries such as jquery or angular), but it is modularised and requires webpack or browserify to use it.
Since our legacy applications do not use the modular approach to loading dependencies, and I have no scope to rewrite them, I would like to somehow package the modularised library into an equivalent js file that will load the library so my application can access it simply via a <script> reference to it.
I have tried using browserify to compile from a source js file that contains simply a require reference to the library, but then referencing the compiled file in my application results in an error as the library's functions are not available to my application.
Can anyone point me in the right direction?
If your using some library's that are module based, and you want to use them standalone, you will need to do 2 things.
expose the module to the global scope. Maybe using the expose loader https://github.com/webpack-contrib/expose-loader or even just assign to the window object.
If the modules are also using a library that your also including standalone, you need to tell webpack about these,.
eg.
{
externals: {
jquery: 'jQuery'
}
// other stuff..
}
Finally when you include these, remember the ordering of your script tags. eg. make sure you include jquery before your bundled javascript.
I'm wondering if there's at least some community consensus on how to write reusable Angular2 code in TypeScript. I tried to summarise what I found out and what I'd like to know in context of Angular2.
Module/App directory structure and file names
In the official tutorial I see they put all code into app directory and all dependencies like node_modules or typings are in the parent directory.
Lowercase file names, .component.ts suffix for components and .service.ts for services. They put all files to the same directory which is going to be a huge mess?
One class/interface/enum per file. For classes, functions, interfaces and other names its probably best to stick to Coding guidelines for TypeScript by Microsoft?
Modules
Should modules compile and bundle themselves using postinstall npm hook? Or is it better to provide bundled version directly on git like most JavaScript libraries do?
Should I stick to system type of modules by default when I'm expecting that my module's going to be used only by browser or is it better to always use UMD?
Is there any reason to use CommonJS or AMD instead of system?
Using 3rd party modules
Should I expect that other developers will embed my modules with <script> tags or they'll load it using System.import()?
If my modules has dependencies on other JavaScript libraries, is it better to provide a bundled version of my whole module with all dependencies or just define them in package.json?
There's the Angular 2 Style Guide (https://github.com/mgechev/angular2-style-guide), as featured in Angular2 News:
The purpose of the following style guide is to present a set of best practices and style guidelines for the development of Angular 2 applications. If you are looking for an opinionated style guide for syntax, conventions...
Angular 1 had a community accepted style guide written by John Papa. There will be something similar created for Angular 2 in fact you can see the start of this coming together with the Tour of Heroes examples in place at angular.io
I have a javascript project were most modules are using some third party libs as 'global' dependencies (in particular jquery and jquery plugins)
I would like to "clean" the project (to express all libraries as requirejs dependencies.), however this is in my case a large task (lots of files, lots of third-party libs).
How could I make the migration easier / quicker ?
Can I "fake" using amd dependencies by wrapping the third-party libs in modules that just load them (with the order! plugin ?)
Is it safe to mix modules that load third-party libs as modulesand modules that directly use the global ?
If I wanted to automate things, are there any tools could I use to 'parse' a requirejs module to tell me if a particular symbol is used ?
Edit : What I mean by my last question is "Would it be possible to automatically rewrite my js files so that hey explicitely import dependencies instead of relying on browser globals ?"
Can I "fake" using amd dependencies by wrapping the third-party libs in modules that just load them
Yes you can, RequireJS has a shim config that is designed just for that.
Take a look at this article it will help you organize your JavaScript code with RequireJS http://www.stefanprodan.eu/2012/09/intro-requirejs-for-asp-net-mvc/
I had a similar question about the need of wrapping third party code in AMD modules. My conclusion was, that there are no benefits in my case (large Backbone app). So you should ask yourself if you really need to import jquery for example per AMD. This will end in modules where you import jquery every time, which is a lot of error prone boilerplate code.
So in short it makes no sense to use AMD for code that you will use in any case.