Package naming convention #786
Replies: 1 comment 3 replies
-
|
There is a problem with code reuse. The dart implementation in the current code (event channel, method invoke code must be consistent, so the current split is flutter native dart and dart HTML if we split all platforms Will code debugging become difficult? |
Beta Was this translation helpful? Give feedback.
-
|
Let me see how the flutter official team plugin does it. |
Beta Was this translation helpful? Give feedback.
-
|
The way you said looks perfect. @wer-mathurin |
Beta Was this translation helpful? Give feedback.
-
|
Our packages look like package platforms implementation |
Beta Was this translation helpful? Give feedback.
-
@cloudwebrtc : If we want to align with what is being done. Here is the naming convention I propose. for pub.dev
webrtc_platform_interface (today this is webrtc_interface)
webrtc_web (today this is dart_webrtc)
(today they are in flutter_webrtc)
webrtc_ios
webrtc_android
webrtc_macos
webrtc_windows
webrtc_linux
flutter_webrtc (this plugin will endorse all of the above and contain only flutter related code)
This will ease the maintenance of each package, tests can be done more easily as well. And I'm confident this will also reduce the build size of the target platform. I think this will also ease the way for an embedded package. Let say Toyota want to include webrtc in their future car for videoconference (when park ! ) this will easy to have an embedded plugin.
I don't have a strong opinion about if this is need to be in a mono repo or multiple repo. But i think this is easier for people that report bug to do it in a mono repo. Otherwise, probably all the bugs will be create in flutter_webrtc. Anyway your call, since you are the main maintainer !
Beta Was this translation helpful? Give feedback.
All reactions