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

feat(fsapp): add fsapp plugin #2784

Merged

Conversation

crherman7
Copy link
Contributor

@crherman7 crherman7 commented Dec 23, 2024

Describe your changes

Created a new @brandingbrand/code-plugin-fsapp package that handles FSApp environment configuration and native module setup. This plugin extracts FSApp-specific functionality from the core CLI into a dedicated plugin, improving modularity and maintainability.

Key changes:

  • Created new plugin package with iOS/Android native module setup
  • Moved FSApp-related transformers and assets to new package
  • Added documentation for plugin usage and configuration
  • Updated environment handling and validation logic
  • Removed FSApp-specific code from core CLI package

Issue ticket number and link

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Test Plan

  1. Run comprehensive unit tests for:

    • Environment file validation
    • Package name validation
    • Path resolution
    • iOS/Android platform-specific transformations
  2. Test package installation and configuration:

yarn add --dev @brandingbrand/code-plugin-fsapp
  1. Verify plugin functionality:
yarn flagship-code prebuild --build internal --env development

Ensure environment switching and native modules are properly configured for both iOS and Android platforms.

Checklist before requesting a review

  • A self-review of my code has been completed
  • Tests have been added / updated if required
  • Documentation has been updated to reflect these changes

@crherman7 crherman7 marked this pull request as draft December 23, 2024 16:16
@crherman7
Copy link
Contributor Author

crherman7 commented Dec 30, 2024

  • requires .flagshipcoderc.json
  • no longer needs envPath in flagship-code.config.ts

We should utilize glob to find all files that match env.<env_name>.ts and then use babel to traverse and verify single default export with the correct import of defineEnv.

glob(<root_dir>/**/env.*.ts) -> babel.traverse -> verify exports/imports -> bundleRequire -> write envs

@crherman7 crherman7 force-pushed the feat/fsapp_plugin branch 2 times, most recently from 9ae11dd to b93a263 Compare January 2, 2025 17:23
Copy link
Contributor Author

@crherman7 crherman7 left a comment

Choose a reason for hiding this comment

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

One thing to notice is that dynamic args is reading from anywhere in node_modules which fails us in a monorepo. We actually should only look at the dependencies and devDependencies installed

@crherman7
Copy link
Contributor Author

One thing to notice is that dynamic args is reading from anywhere in node_modules which fails us in a monorepo. We actually should only look at the dependencies and devDependencies installed

fixed in latest

Comment on lines -365 to -376
if ((message as any) instanceof Error) {
const errorStackArr = (message as any).stack.split(
'\n',
) as unknown as Array<string>;

errorStackArr.shift();

FlagshipCodeManager.shared.emit(
'onLog',
chalk.dim('\n' + errorStackArr.join('\n')),
);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this needs to be looked into further

Copy link
Contributor Author

Choose a reason for hiding this comment

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

there is no great way to split the stack from the error message, so we may just want to display the stack instead since it includes both - the stack can be useful.


async function validateEnvFiles(baseDir: string): Promise<string[]> {
const pattern = path.join(baseDir, '**', 'env.*.ts');
const files = glob.sync(pattern, {ignore: '**/node_modules/**'});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can collect files here but how can we guarantee that these are intended to be env files...we shouldn't just throw an error due to it being named in a particular way but not conforming to a format. this could be a different file used for something else. something to think about

},
});

if (!hasDefaultExport) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

we should likely only throw an error here if the import does not exist that way we know it's supposed to be a runtime env

Copy link
Contributor

@NickBurkhartBB NickBurkhartBB left a comment

Choose a reason for hiding this comment

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

looks good to me, just some minor nitpicks or questions

apps/docs/src/content/docs/packages/plugin-fsapp.mdx Outdated Show resolved Hide resolved
packages/cli-kit/src/lib/FlagshipCodeManager.ts Outdated Show resolved Hide resolved
packages/cli/src/actions/dependencies.ts Outdated Show resolved Hide resolved
@@ -0,0 +1,464 @@
/// <reference types="@brandingbrand/code-cli-kit/types" />
Copy link
Contributor

Choose a reason for hiding this comment

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

this file is fairly large, wonder if we should break up

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is probably another thing we can do as well, it will minimally help with readability and testing without exporting those functions through the main plugin.

}

if (!hasDefineEnvImport) {
throw new Error(
Copy link
Contributor

Choose a reason for hiding this comment

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

I feel like this one might be more of a warning, I believe it will still work if they don't use defineEnv

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah I was thinking we need to not necessarily throw an error for certain things but we need a way to know it's an env file

options: PrebuildOptions,
): Promise<void> {
logger.log('Processing environment files for Android...');
await processAndLinkEnvs(options as any);
Copy link
Contributor

Choose a reason for hiding this comment

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

seems like we need to repeat this step in both android and iOS cause we don't know if one or both are running. I wonder if we need to build in another way to run these type of things, though this may be a unique case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah we will add a "universal" or something like that that will run once that has no relation to a particular platform when we move to presets and plugins

* @returns {Promise<void>} A promise that resolves when environment processing is complete.
*/
async function processAndLinkEnvs(
options: PrebuildOptions & Record<string, string>,
Copy link
Contributor

Choose a reason for hiding this comment

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

should this be PrebuildOptions & {env?: string}? so we don't have to cast the call sites to any?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So for now the call sites will still need to be casted because of the explicit nature of the definePlugin where the options are defined as explicitly the prebuild options....going to update the type to be non-breaking.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated to allow this.

@crherman7 crherman7 marked this pull request as ready for review January 13, 2025 16:55
packages/plugin-fsapp/__tests__/platform.ts Outdated Show resolved Hide resolved
packages/plugin-fsapp/__tests__/platform.ts Show resolved Hide resolved
packages/plugin-fsapp/__tests__/platform.ts Outdated Show resolved Hide resolved
packages/plugin-fsapp/__tests__/platform.ts Outdated Show resolved Hide resolved
@NickBurkhartBB NickBurkhartBB merged commit 632e384 into brandingbrand:feature/app-router Jan 15, 2025
1 check passed
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.

2 participants