Develop Reference

NativeScript Version 8.2.1 : how to use old outdated plugins

I am new to NativeScript and Webpack and i have migrated my native script app from 6.5.1 to 8.2 version, and i am using nativescript-orientation-free plugin ,i am getting build errors as this plugin still refers to tns-core-modules which is no longer supported in Native Script 8 and i am getting below errors
ERROR in ./node_modules/nativescript-orientation-free/orientation.js 17:12-48
Module not found: Error: Can't resolve 'tns-core-modules/ui/enums' in '/Users/admin/Development/project/node_modules/nativescript-orientation-free'
ERROR in ./node_modules/nativescript-orientation-free/orientation.js 18:12-48
Module not found: Error: Can't resolve 'tns-core-modules/ui/frame' in '/Users/admin/Development/project/node_modules/nativescript-orientation-free'
we do not want to use this paid version pro-plugins-nativescript-orientation
can you please let me know how can i fix this issue? is there anything i can do in the webpack.config.js ? I am stuck here.

You have my sympathies. (A quote from the movie Alien.)
Migrating a NativeScript app from 6.5 to 8.x can be wildly frustrating due to all the breaking changes. Make sure you watch this video: Migrating Legacy NativeScript 6 Project to 8.
When Migrating my app I found I had to migrate several of the plugins I used. Patch-package is your friend! To answer your question, you'll need to revise the links you circled. Sometimes this is easy, sometimes this requires investigation.
These three should work:
import { Application as application } from '#nativescript/core';
const Enums = require("#nativescript/core/core-types").Enums;
import { Frame as frame } from '#nativescript/core';
I expect these two should work, 'tho I didn't use them in my project:
import { Page } from '#nativescript/core';
import { View as view } from '#nativescript/core';
Good luck!

i removed this plugin and able to set the orientation without any third party plugins using
UIDevice.currentDevice.setValueForKey(1, "orientation");

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

How to set application version on the Sentry error capturing?

Recently, I installed Sentry on my React Native application. I set my initializing configuration like below:
import { SentryToken } from './app/helpers/config';
import { environment } from './app/helpers/env';
Sentry.init({
dsn: SentryToken,
environment,
});
And on the issue dashboard, I can see all errors, messages and etc.
But in one of the message report I saw the Sentry reports whole the device, OS and especially the application:
Actually, I wanna know where does the version come from?
I even pass the version key but still, it doesn't make any difference the version in the Sentry dashboard is still on 1.0`.
I read whole the documentation about options but there is nothing to help me.
where does the version come from?

Finally, I find out sentry brings the Version and the Build number from Xcode:
Actually, these two numbers come from the info.plist file and project.pbxproj file with the following file:
info.plist: ios/[projectName]/Info.plist
project.pbxproj: ios/[projectName].xcodeproj/project.pbxproj

Conditional import of React Native library

I want to import a React Native library for Android only, as there is no iOS version.
I have the current setup (I used require to get around import restrictions):
if (Platform.OS === 'android') {
BackgroundColor = require('react-native-background-color');
}
But this still fails out on iOS.
Is there a standard way to do this? I can't find any documentation on it.

This issue has been already fixed by one of the PR (https://github.com/ramilushev/react-native-background-color/pull/8) which has been merged. but, owner of the library has not published the new version.
So, until new version is released, as a workaround you can manually add blank index.ios.js file in node_modules/react-native-background-color/ directory to resolve your import issue in ios. Alternatively you can fork the library.

Can't use absolute paths for import?

Bear with me, I'm not sure if this is purely a React Native issue, or just an ES6 question in general. But I noticed I'm unable to do this:
import {navBarRouteMapper} from '/src/helpers';
I get an error saying it's unable to resolve the module. I have to do this instead:
import {navBarRouteMapper} from '../../../src/helpers';
Keeping track of folder depth can get a bit unmanageable as the complexity of the app grows. Why am I not able to use an absolute path?
EDIT:
I see people are recommending adding babel, but I don't want to pollute React Native's system. There's obviously transpilation to ES6 already going on. I was hoping for a solution specific to the React Native ecosystem.

There is actually a pretty clean solution for React Native, have a look here: https://medium.com/#davidjwoody/how-to-use-absolute-paths-in-react-native-6b06ae3f65d1#.u47sl3p8x.
TL;DR:
You'll just have to create a package.json file in your src/helpers folder:
{
"name": "#helpers"
}
And you will be able to import it from anywhere:
import { navBarRouteMapper } from '#helpers'