Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BabylonReactNative Basekit frontend package #615

Draft
wants to merge 26 commits into
base: master
Choose a base branch
from

Conversation

CedricGuillemet
Copy link
Contributor

@CedricGuillemet CedricGuillemet commented Oct 20, 2023

Front end package named @babylonjs/react-native-basekit that downloads and installs necessary component for iOS/Android or Windows. Same as 'legacy' basekit (no XR or Camera).

  • exception/error handling: I can see errors reported by the package when doing npm install with PG
  • env vars for URL sources
  • Cache mecanism
  • Test with playground test app iOS/Android/Windows
  • forward release from github release in publish.yml
  • npm install react-native@latest -> does it re-run package post install? Yes it does!
  • npm install BRN then install react-native-windows -> is BRN package updated as well ? No, I had to run npm ci Is it normal usage ?
  • readme updated without mention of permissions. Also removed package name depending on react-native version

@CedricGuillemet CedricGuillemet changed the title Append release Babylon react-native basekit Oct 20, 2023
Copy link
Member

@RaananW RaananW left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a few comments on the install script :-)

Modules/@babylonjs/react-native-basekit/scripts/install.js Outdated Show resolved Hide resolved
Modules/@babylonjs/react-native-basekit/scripts/install.js Outdated Show resolved Hide resolved
Modules/@babylonjs/react-native-basekit/scripts/install.js Outdated Show resolved Hide resolved
Modules/@babylonjs/react-native-basekit/scripts/install.js Outdated Show resolved Hide resolved
Modules/@babylonjs/react-native-basekit/scripts/install.js Outdated Show resolved Hide resolved
Modules/@babylonjs/react-native-basekit/scripts/install.js Outdated Show resolved Hide resolved
}
} else {
console.error("No react-native version found for BabylonReactNative.");
process.exit(1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

general idea (totally not a must) if you want to catch the exact error (for example during CI testing), give them different code values

Modules/@babylonjs/react-native-basekit/scripts/install.js Outdated Show resolved Hide resolved
Modules/@babylonjs/react-native-basekit/scripts/install.js Outdated Show resolved Hide resolved
@CedricGuillemet CedricGuillemet marked this pull request as ready for review October 25, 2023 09:16
@CedricGuillemet CedricGuillemet changed the title Babylon react-native basekit BabylonReactNative basekit frontend package Oct 25, 2023
@CedricGuillemet CedricGuillemet changed the title BabylonReactNative basekit frontend package BabylonReactNative Basekit frontend package Oct 25, 2023
Modules/@babylonjs/react-native-basekit/README.md Outdated Show resolved Hide resolved
Modules/@babylonjs/react-native-basekit/README.md Outdated Show resolved Hide resolved
Modules/@babylonjs/react-native-basekit/README.md Outdated Show resolved Hide resolved
Modules/@babylonjs/react-native-basekit/README.md Outdated Show resolved Hide resolved

Babylon React Native supports react-native from 0.69 to 0.71+. See project Github main readme for supported versions.

### `useEngine`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this duplicated documentation? Is the plan that once we are fully on this new packaging scheme, we delete the old stuff?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it's duplicated from @babylonjs/react-native readme. long term is indeed to replace old legacy packages by this one.

Modules/@babylonjs/react-native-basekit/scripts/install.js Outdated Show resolved Hide resolved
Modules/@babylonjs/react-native-basekit/scripts/install.js Outdated Show resolved Hide resolved
fs.mkdirSync(dir, { recursive: true });
}
} catch (err) {
reject(err);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are all these reject(err) calls supposed to be cb(err)? It doesn't seem like there is a reject in this context since it is not Promise based. I wonder if it would be better to write this in TypeScript and have a step to compile it to JavaScript?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's be better to use TS. For a future PR? I'm pretty sure this new package will needed adjustments and bug fixes.

}
}

install();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this a fire and forget async call? Will the npm install somehow wait for this operation to complete, or could this still be running after the npm install thinks it finishes? I thought I read somewhere it is possible for npm post install scripts to be async...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In practice, it looks like npm waits for the install to finish. Can you confirm @RaananW ?

.github/workflows/append_release.yml Show resolved Hide resolved
Comment on lines 27 to 28
files: | # all files except package.json and readme.md
BabylonModule.d.ts
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a better way to handle this? I would rather we avoid keeping lists in a yml file. Seems error-prone if someone adds a file and doesn't realize there is a list here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All this is to avoid copying (and overwriting) package.json. I agree it's error-prone. atm, I only see more convoluted ways (a prepass that copies files, a js script that lists files,...)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there were a way to exclude files for tar, would that work?

Copy link
Contributor Author

@CedricGuillemet CedricGuillemet Nov 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, we do a PR to https://github.com/a7ul/tar-action
Looks like we are not alone : a7ul/tar-action#21

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be okay to call tar from the shell?

.github/workflows/append_release.yml Show resolved Hide resolved
return [site, package.version, binaryFilename].join("/");
}

function downloadExtractAndCache(url, cachedFilePath, cb) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like this file could benefit from using async/await instead of callbacks. It would remove a bunch of the callback chaining and make error handling better.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess so. Usage of type script might help as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meh, maybe. TypeScript is probably a bit overkill. Anyways, it's not a big deal either way.

@CedricGuillemet CedricGuillemet marked this pull request as draft December 5, 2023 10:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants