Develop Reference

Unable to fix Node Path in packaged Electron App

I'm building a simple Electron app for MacOS (using React as the frontend). The purpose of the app was to make executing certain terminal commands a lot easier (using child_process.spawn. Primarily I am interested in using the sfdx Salesforce CLI commands.
When I run the app in dev, everything works fine. However when I package the app, the PATH variable gets changed and I'm no longer able to locate the sfdx library. (*note it is still able to find git commands though).
I found a very similar issue here and a bug report in GitHub, both of which recommend the use of the fix-path package. This is where I run into another issue. According to the docs, I should import the package like this:
import fixPath from 'fix-path';
However when I do that inside of my electron.js file I get this error: SyntaxError: Cannot use import statement outside a module. I've seen other resources that use require to bring in the package:
const fixPath = require('fix-path');
But again, when I do that I get this error require() of ES Module not supported.
I tried adding "type": "module" to my package.json file, but that breaks my app as well.
I feel like there is something simple that I am missing here, but can't seem to figure out. I believe that if I could import and use the fix-path package, then this would solve my problems. But if that isn't possible, does anyone know of a way for me to fix the path in my app so that it works in prod?
Thank you in advance!
Some extra details:
The two dependencies I check for are git and sfdx. The following image shows where both of those live on my machine:
And this is the response to the same commands within the packages asar file:

I found a workaround, it looks like fix-path made a move to ESM during the last release. Because I am using CJS modules I just needed to install version 3 of fix-path by running npm install fix-path#3.0.0 --save

Other way to share react ts components between projects

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.

Import local JS files into Meteor

I'm having terrible problems when trying to import an external JS project into my meteor folder. This is the project I'll like to use: http://www.outsharked.com/imagemapster/default.aspx?demos.html#beatles
As you can see, it is necessary to import two scripts. The first one is JQuery, and that was easily solved by adding it with meteor add jquery.
The problem came out when I tried to import the second script. I'm not sure how I can use it because, as far as I know, on meteor you cannot just import your script into the head section. For that reason, I've created a new template that is rendered and I put the code in there, but nothing happenend. Later on I've created an event that calls the JS when the image is clicked but without any success.
My question is, Which is the correct way to import a local JS code in meteor as in HTML is done with:
<script type="text/javascript" src="../dist/jquery.imagemapster.js"></script>

Since jquery-imagemapster is available as an npm package you can do:
$ npm install jquery-imagemapster
In your project directory and make it available to your project that way.
In early versions of Meteor packages were only available via atmosphere and $ meteor add. Later they added npm support and all npm packages became available.

Prefix npm installs with “meteor” -> “meteor npm install —save ‘js file’. Initializing will be the same as it would be in any other front end environment as will importing it. If you’re having trouble after that, check for it’s existance in your browser console and work from there using its built in properties and methods.

Deploying AngularJS 1.x - Webpack app to Tomcat

I've searched all over google and checked out the official docs for Webpack but have not had any luck finding a tutorial/guide/plugin to even do this. Has anyone done this before or should I just drop webpack altogether and go for a grunt-maven-war file generator instead?

Well, there is nothing special in building spring-boot with webpack. You can install node globally, you can install it during build...
You just add plugin to pom.xml to run node command i.e. (https://github.com/eirslett/frontend-maven-plugin)
And that actually it. It runs webpack and you get your js, css, fonts, ... files in some folder. Now you proceed like it is usual static assets, pack them into war and enjoy.

Using Leaflet with plugin in Meteor

I'm building an app with Meteor 1.3, and I need Leaflet and leaflet-measure. I've installed both with NPM, and import them to my file with import. I have a simple template with a map-div, and a corresponding JS-file with a onRendered-callback. It creates my Leaflet-map and it works.
The problem starts when trying to add Leaflet-measure:
Using NPM and importing tells me that a method in fs is missing, but installing and importing that as well does not help.
I've tried adding the dist-files to a lib-folder in client and importing them, but I get an error that indicates that the code hasn't been run:
How can I make a plugin like this work with Meteor?