there is another unfortunately named post that appears to be asking the same question, but is, in fact, not. this is actually asking how to do what I asked specifically.
I have a situation where we can't use NPM. not being as familiar with JS as I'd like to be, I want to use the vueDataTables library, but don't know how (or if) I can bypass the NPM-only install instructions and just download, link, and use it locally.
more generally, how would one use an NPM installed library when you don't have or can't use NPM and need to link the library locally?
You can download the zip build file, and add it to your source code, then you can import it using the local path. For example
import DataTables from './lib/vuewthing/dist.js
Or add the source files from that library and point to them, but that will slow down your build times and performance.
If they don't have a downloadble build, you can clone it, and build it, and then paste the built files to your source.
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.
I made a Javascript file. Let's say the contents of it are this:
let myCoolAlert = (str) => {
alert(str)
}
// in a different js file (SO doesn't allow you to cross-file as far as I know
myCoolAlert('Hello World!')
I already hosted the JS file on a CDN. Now, I want it to be automatically hosted locally by whoever installed it if you install it via NPM. Is there a way to do this?
Also, I noticed that to do the same using Socket.io, you have to pass Socket.io to the HTTP/HTTPS server you created. Will I have to do this also? (I would prefer not).
Thanks!
Edit:
I am trying to make a better alert system (like sweetalert). I coded it in Javascript and works when using it through the CDN. However, I also want users to be able to install this via NPM (kind of like SweetAlert? I am not sure about that last statement however because I do not use it). When they install it with NPM, it's obviously going to be useless because it is for the browser. However, I want them to either:
Automatically have the source code needed available at a URL like localhost:3000(or server name)/betterAlert.js and be able to use that URL as a script in the HTML files
OR, have the user pass the HTTP or HTTPS server they created to the module (like socket.io does) and have it automatically host it from there.
Please note:
The code I am trying to bundle is native to the web. Will it still work with a bundler like webpack?
Is this possible? Thanks again.
To bundle client-side code and publish it through NPM you'll need to do a couple things: learn how to package and publish modules, and write some code that can be consumed. This means using module.exports or export to expose your library, depending on whether you want to use CJS or ESM. The consumer of your library can usually be assumed to be using Webpack, Fuse, Rollup, or some other bundler which knows how to deal with modules.
You can also use a tool like Rollup yourself to build and bundle up your library for different targets and apply various transformations to it (example from my own library boilerplate). Using a bundler like this makes more and more sense as your library inevitably grows larger.
Using modules like this rather than distributing through a CDN or in some other way that puts your library code on the global/window object is generally better for consumption in complex apps, large apps, and/or apps already being built with tools like Webpack (so, anything written in React, Angular, Vue, etc.). But having a CDN distribution is still a good idea for something like your library, since it may well be used by people building sites with jQuery and vanilla JS.
I have a `js` file that will use a third party library installed with `npm`. This file will be downloaded to the project when we go to a certain page.
Since the third-party library is used only on this page, I do not want to include it in the project, that is, I want to download it along with the js package. What I need to use for creating a js package which will contain all dependencies? I've been looking all day, but I can't find the solution.
I solved the situation like this: I copied the content of a third-party library and pasted it into a JS file before my code.
It can also be done using a webPacker by this guide
Javascript dinosaur here. Back in the good old days, customizing a JS library was pretty easy. I'd download the non-minified version, put that sucker on the /js folder, do the changes necessary to the code and embed it on the html. Like this:
<script src="Sortable.js"></script>
Enter the marvelous world of modern javascript, a great advance where no project folders have less than 14mb. In this world, I don't download the file and put it on the /js folder, I install the package with 12 warnings and import it, and then a little program compiles it for me every time I need to test it. Takes 10x longer, but hey, my code is now compatible with the 0.0003% of users who use Internet Explorer 4. Wonderful. Anyway, this is the modern code:
import Sortable from 'sortablejs/modular/sortable.core.esm.js';
Sarcasm aside, I have a serious question: When customizing a library in a modern setup, of course, I won't change the final compiled version as it would be overwritten in a new build. I also wouldn't change the files sitting in node_modules folder, because these will be overwritten with every update. So what's the best way to do this?
Something tells me I have to fork the library, put the fork on npm and import the fork. I don't want to believe it. Is this really what I have to do to customize literally 2 lines of code?
If I had such a task, I would rather download the source code, do the changes, build it, and "install" it as a dependency using Local Path:
{
"name": "project",
"dependencies": {
"sortablejs" : "file:../path/to/sortablejs/bin"
}
}
But it's difficult to update the package with those changes. That's why you may consider using something like patch-package or using Yarn's yarn patch <package>, which lets you keep your changes separately from your package (in theory, I've never used it before).
I'm using a package that loads Font Awesome from a CDN. However, the CDN used is pretty terrible, often stalling or timing out, so I'd like to switch it out.
The source code is incredibly simple, and looking through it I found this:
style.href = '//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css';
Switching to a different CDN would only require changing this one line (I presume), but the problem is I don't know how! Or rather, I don't know where it is available in my project.
How do I actually do this?
Create a packages/ directory at the top level directory of your app (myapp/packages) and simply git clone the package you want to modify into it.
Add the package via meteor add and you'll be able to edit the files of the package you just cloned.