Develop Reference

Circular dependency (?) in library & nodejs library code - Object prototype may only be an Object or null: undefined

I'm using filestack-js in a Rails project which is bundled with Vite. Everything works as expected until I include the ESM module for the filestack-js library, in this case in a StimulusJS controller:
import { Controller } from "stimulus";
import * as filestack from "filestack-js";
export default class extends Controller {
// some irrelevant implementation code that calls filestack.init(...)
}
Loading the above controller file in the browser causes an error:
tslib.es6.js:25 Uncaught TypeError: Object prototype may only be an Object or null: undefined
at setPrototypeOf (<anonymous>)
at __extends (tslib.es6.js:25)
at http.ts:43
at node_modules/filestack-js/build/module/lib/request/adapters/http.js (http.ts:64)
at __init (chunk-IHTDASF6.js?v=1616a449:14)
at request_adapter.node.ts:17
This is an error produced by the browser while working in a development environment, using Vite to build and serve ES modules to the browser directly. It handles Typescript compilation. Removing the import * as filestack bit makes the error go away (but obviously breaks the class' functionality).
My google searches seem to suggest that this might be a circular dependency problem. The browser stack trace points towards a file in the filestack-js library:
// src/lib/request/adapters/http.ts
import * as url from 'url';
import * as zlib from 'zlib';
import Debug from 'debug';
import { AdapterInterface } from './interface';
import { getVersion } from '../../utils';
import * as Stream from 'stream'; // <---------- Stream imported here
import { FsRequestOptions, FsResponse } from '../types';
import * as utils from '../utils';
import { prepareData, parseResponse, combineURL, set as setHeader, normalizeHeaders } from './../helpers';
import { FsRequestErrorCode, FsRequestError } from '../error';
import { FsHttpMethod } from './../types';
const HTTPS_REGEXP = /https:?/;
const HTTP_CHUNK_SIZE = 16 * 1024;
const MAX_REDIRECTS = 10;
const CANCEL_CLEAR = `FsCleanMemory`;
const debug = Debug('fs:request:http');
class HttpWritableStream extends Stream.Writable {
// omitted class definition
}
Where Stream.Writable is actually undefined due to a circular dependency problem. I have no idea how that would happen or seem to only affect me.
This is not an issue that has been reported on the filestack-js issue tracker.
Debugging in the browser and cloning/linking the repository locally have confirmed that Stream.Writable is returning undefined, but I don't know enough about JS to understand why. Supposedly this typically happens due to a circular dependency, but I'm not sure how the nodejs Stream module would have circular dependencies on a random library like filestack-js. I am also inexperienced enough in the JS world to understand exactly what it means to be using a nodeJS library like Stream in a browser module - filestack-js has both browser modules and commonJS/nodeJS modules so I'm not sure how/if they relate or interact.
Here's what the Stream object looks like when logged to a browser console. Clearly something has been imported but Writable is not a property of what was imported:
FWIW this happens on Chrome and Firefox, latest versions of each.
I also tried using dpdm to analyze the filestack-js project for circular dependencies. It did find some but it doesn't appear as if they are causing errors, and it does seem to explicitly be excluding node libraries and other dependency libraries.

Ok I think I've solved my issue but I'm not an expert so I'll try to explain what the problem was. Feel free to chime in with clarification if you know better.
This was caused by filestack-js's heavy usage of nodejs libraries. Historically, Webpack v4 has polyfilled a lot of common NodeJS libraries for usage in-browser, entirely transparent to most developers. This worked great but was complete magic.
Rollup, and incidentally, Webpack v5, do not do this polyfilling, so any nodeJS libraries used by "ESM" libraries from NPM that aren't directly compatible with modern browsers will just break. In order to polyfill this manually I had to instruct Vite & Rollup to alias the name of the nodejs stream module to something that is directly compatible with browsers, and install that. To do that, I:
yarn add --dev stream-browserify
And added the following to my vite.config.js:
// ...
resolve: {
alias: {
stream: "stream-browserify",
},
},
// ...
There should be a very similar (but different) way of telling Rollup to do this, because here I do it though the Vite configuration.
For extra context, here is the GitHub issue I opened on the filestack-js repo: https://github.com/filestack/filestack-js/issues/458

Imported it directly as recommended in the link Taylor recommended.
import * as filestack from 'filestack-js/build/browser/filestack.esm';
https://github.com/filestack/filestack-js/issues/458#issuecomment-927373100

Flow complains about untyped import

I'm starting out on a React Native project that uses react-native-geolocation-service to get the user's GPS location, but Flow is complaining that the library is untyped. The library has Typescript types, but doesn't seem to have Flow types, and VS Code gives me this error when I import the library.
Importing from an untyped module makes it any and is not safe! Did you mean to add // #flow to the top of react-native-geolocation-service? (untyped-import)Flow(LintError-untyped-import)
Can I convince Flow to stop complaining about this library, or should I switch to Typescript? I don't have any particular preference for Flow, it's just what react-native init set up for me.
I used this to create the project:
npx react-native init WarmerWalker
Then I added the library like this:
npm install react-native-geolocation-service
I import the library like this in my App.js:
import Geolocation from 'react-native-geolocation-service';
I tried adding the library to the untyped section in .flowconfig, but that didn't help. Neither did the ignore section.
The code seems to work, it's just making Flow complain.

Thanks to a comment from Alex, I learned about strict mode. The sample app that react-native created used #flow strict-local, so that was causing the problem. Removing strict-local made it stop complaining.
However, since the library I want to use has Typescript type definitions, I'm going to switch to Typescript. I regenerated the sample app with the Typescript template, like this:
npx react-native init MyApp --template react-native-template-typescript

Why would `import dataTables from 'datatables.net'` work on some machines but not others?

We have a single-file Vue 1.x component that is a wrapper of dataTables. The basics of it look like this:
<template>
...
</template>
<script>
import Vue from 'vue';
import $ from 'jquery';
import dataTables from 'datatables.net';
import dataTablesSelect from 'datatables.net-select';
import dataTablesColReorder from 'datatables.net-colreorder';
import dataTablesScroller from 'datatables.net-scroller';
const Table = Vue.extend({
...
created() {
$.fn.dataTable.ext.errMode = 'throw';
...
this.dataTable = this.$table.DataTable(this.options);
},
});
</script>
The component is compiled via our Webpack configuration.
This has worked just fine. Recently we have been porting the codebase to Vue 2.x. On mine as well as my coworker's machines, the ported component works great. However once it has been built on our build server, using the same command, it instead throws this error on page load:
TypeError: Cannot read property 'ext' of undefined
referencing the line above:
$.fn.dataTable.ext.errMode = 'throw';
It seems then that when built on our build server, dataTables is not actually getting properly imported. I can confirm it is the actual generated app.js causing the issue, as downloading it and running it locally generates the same error. I've tried everything I can think of to match environments including making sure node/npm versions are the same and rm -rfing node_modules. Yet we still repeatedly get the same results.
I'm out of ideas on where else to debug, as admittedly I am not well versed in the mechanics of a webpack build. What could possibly be causing this to seemingly only work on certain machines?

That error means there is no $.fn.dataTable object.
Post your webpack mix file and how you're using jQuery. I'm suspecting that external/multiple jQuery conflict here, where you import one jQuery and the DataTable is initialized on a different jQuery. See if this work.
// Right below your imports, initialize everything you imported
// this make sure fn.dataTable get initialized on the imported jQuery
// which is reference as $ in this case
dataTables(window, $);
dataTablesSelect(window, $);
dataTablesColReorder(window, $);
dataTablesScroller(window, $);
Shameless plug, check out my wrapper here - https://github.com/niiknow/vue-datatables-net - it may help make things easier for you. Even with my wrapper, you have to still know which jQuery you're initializing it on.

Using Vue Design System in Nuxt is throwing errors about export in system.js

I am trying to get the components imported into a Nuxt project, following the steps here:
https://github.com/viljamis/vue-design-system/wiki/getting-started#using-design-system-as-an-npm-module
Nuxt does not have a main.js (everything is plugin based), so what I have done is create a "plugin" and then do the import code in there like so (Nuxt recommends this for other libraries too and works fine):
vue-design-system.js
import Vue from 'vue'
import system from 'fp-design-system'
import 'fp-design-system/dist/system/system.css'
Vue.use(system)
Then in my config I do (removed other code in config):
nuxt.config.js
module.exports = {
css: [
{ src: 'fp-design-system/dist/system/system.css', lang: 'css' }
],
plugins: [
{ src: '~plugins/vue-design-system', ssr: true }
]
}
When I run npm run dev in my theme, it builds, but I get a warning:
WARNING Compiled with 1 warnings warning in
./plugins/vue-design-system.js 7:8-14 "export 'default' (imported as
'system') was not found in 'fp-design-system'
Seems to have an issue with the generated system.js regarding the export (the command npm run build:system).
In my page on screen I get the following error when trying to use a component in the design system:
NuxtServerError Cannot find module
'fp-design-system/src/elements/TextStyle' from
'/Users/paranoidandroid/Documents/websites/Nuxt-SSR'
If I hard refresh the page, I then get another message:
NuxtServerError render function or template not defined in component:
anonymous
Any idea what's happening here? It would be really great to get this working somehow.
At this current time, I'm not sure if it's a Nuxt issue or a Vue Design System issue. I think the latter, just because the Nuxt setup I have right now is very bare-bones...so it's not something else causing this.
Thanks.
Repository on GitHub:
Here is the repo for my "theme", but in order to get this going, you will need to create a design system separate from this with the same name and follow the steps to use the design system as a local (file) NPM module.
https://github.com/michaelpumo/Nuxt-SSR
console.log of system (from the JS import statement)

As for your first error (""export 'default' (imported as 'system') was not found in 'fp-design-system'"), the UMD built JS from vue-design-system does not export a "default" object. But you can simply workaround the issue by importing it as:
import * as system from 'fp-design-system'
instead of:
import system from 'fp-design-system'
Then another issue comes quickly as you noticed in your comments: "window is not defined", due again to the UMD built JS that expects window to be globally available, instead of the usual trick to use this (which equals window in a browser). Therefore as it is, the build is not comptible with SSR.
You could however slightly rework the built JS by replacing the first occurrence of window by this, but I am not sure if the result will still work.
Most probably you should better keep this module for client rendering only.

It seems Vue is looking for the ES6 pattern for importing module, which you should use for external javascript modules/files.
in ES6 it is
export default myModule
in ES5 it was
module.exports = myModule
Hope it will help.

Import Browserify package into Ember-Cli project

I've installed the following library via bower: https://github.com/kaimallea/isMobile/blob/master/isMobile.js
And imported it into my ember-cli project via in ember-cli-build.js:
app.import('bower_components/isMobile/isMobile.min.js');
While it's available via window, I also want to use it directly in Fastboot mode in node.
You can see in the source of the library, that it actually exports itself for Browserify via module.exports = instantiate();, so I tried to import it via
import isMobile from '../bower_components/isMobile/isMobile.min.js';, but that throws
Error: Could not find module "frontend/bower_components/isMobile/isMobile.min.js" imported from "frontend/helpers/is-mobile-test"
I think I'm just missing something obvious.

The mentioned library seems to be available as a node module as well. You can declare it as a fastboot dependency and execute it as mentioned in their docs when the app runs in fastboot mode