-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
chore(cordova): build and depend on plugin in build/ #1521
base: master
Are you sure you want to change the base?
Conversation
Damm, I need to figure out how to have the plugin in the package.json, but not be installed.... |
This strengthens the case for a per-platform approach no? Think of a structure like this: /cordova
/ios
/plugin
build.action.mjs # => when called, calls cordova/plugin/build ios, populating cordova/ios/plugin
/macos
/plugin
build.action.mjs # => when called, calls cordova/plugin/build macos, populating cordova/macos/plugin
/android
/plugin
build.action.mjs # => when called, calls cordova/plugin/build android, populating cordova/android/plugin
/plugin
build.action.mjs |
Yes, this PR needs to change to build the plugin for each platform. I was thinking of a structure like this inside
By appending the buildmode to the directory, we can have the builds coexist and not interfere with each other. It also prevents the release of debug code. It also makes it clear that that component takes the build mode into account. |
Here's my ideal: each platform project has a .gitignore'd I think this is an okay intermediate step, seeing as how the current build is centralized in the root and we'd need improvements to our build infrastructure to realize this vision. |
|
||
import {cpSync, mkdirSync} from 'fs'; | ||
import path from 'path'; | ||
import rmfr from 'rmfr'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussion it seems we have references to packages with duplicated functionalities, like rmfr
here is duplicated with rimraf
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm justing reusing what was already being used somewhere else. I think rimraf
is a command line tool?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rimraf
is both a node library and a cli implementing rm -rf
. I think it's ok for this pr, we may clean them up in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i believe rimraf doesn't support async, rmrf doesn't have a cli
to clean it up, we'd need an async wrapper for rimraf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, just some ideas/comments
@@ -152,6 +152,6 @@ | |||
] | |||
}, | |||
"workspaces": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we can remove the workspace for now, it's not persistent anymore
await rmfr(PLUGIN_OUTPUT); | ||
await mkdir(PLUGIN_OUTPUT, {recursive: true}); | ||
|
||
await cp(path.join(process.env.ROOT_DIR, 'src', 'cordova', 'plugin'), PLUGIN_OUTPUT, {recursive: true}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we prefer to use getRootDir
? Just for the sake of consistency. We can do something similar with buildDir later (i would prefer it to be a parameter)
const ANDROID_LIB_DIR = path.join(PLUGIN_OUTPUT, 'android', 'libs'); | ||
await mkdir(ANDROID_LIB_DIR, {recursive: true}); | ||
await cp( | ||
path.join(process.env.ROOT_DIR, 'third_party', 'outline-go-tun2socks', 'android', 'tun2socks.aar'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit - how would you feel about having a "apple dependencies" array and a "android dependencies" array and then iterating over those here?
@@ -0,0 +1,96 @@ | |||
// Copyright 2022 The Outline Authors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how would you feel about this living in src/cordova/plugin
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(so it would be src/cordova/plugin/build
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this would require moving the plugin source into a subfolder in cordova/plugin
For some reason this is succeeding on the CI, but was failing from XCode for macOS. I'll wait for #1527 to be in, before making this one work for real. I don't want to block that one, which is higher impact. |
By adding a first stage to build the plugin and depend on it in the build directory, it will be a lot easier to make the plugin standalone.
This also paves the way to create the Cordova project in build/, which will allow us to do smarter things, like having different config.xml per platform, inject version numbers, but also get rid of the www/, platforms/ plugin/ in the root, and simplify clean.