Nativescript: MaterialComponents pod version

[farfromrefug]

in {N} 6 your require MaterialComponents at a specific version: https://github.com/NativeScript/NativeScript/blob/36322564ac8fcced6923cc9ef5e057067076061d/tns-core-modules/platforms/ios/Podfile#L4

This will force my plugin nativescript-material-components to use MaterialComponents 84.x
This is a big issue because it create a warning while publishing an app https://github.com/material-components/material-components-ios/issues/8381

They fixed it in 91.0.0.
I know you have a PR about allowing to override versions in app Podfile but that is not enough. May i ask why to force the version in such a way?

I think you should not specify the version and let the user force it if he wants. Also it wont break modules like mine which right now cant use any feature implemented in > 84

[MartoYankov]

@farfromrefug We are using the MDCTabBar component in the core modules, which was tagged as "To Be Deprecated" in v85. We decided it's not safe to allow newer versions of the material components library at the time. I see there is a new component MDCTabBarView that we should use in its place. It seems the library is iterating very fast (8 major releases in less than 5 months) with lots of breaking changes and deprecations. I will check if we can update to latest now, but ultimately we don't feel it's safe to say the core modules can work with any new version.

In the long term I think it would be best to check if we can drop the lib from the core modules.

[farfromrefug]

@MartoYankov I totally agree, why not move it inside nativescript-material-components. Seems like the best solution. Let me know if i can help. Right now this is kind of a big issue. Don't know when Apple is going to refuse our apps because of the issue mentioned up there.
All users of nativescript-material-components will face it.

[MartoYankov]

@farfromrefug We can try updating the dependency to '~> 92.3' for {N} 6.2 which will be released at the end of the month. Will that work for you?

[farfromrefug]

@MartoYankov You mean migrating to MDCTabBarView ? But yes would be great to get above 91.0.0

Tahnks again!

[MartoYankov]

@farfromrefug No, the MDCTabBar is deprecated, but not yet deleted in latest.

[farfromrefug]

@MartoYankov I am facing that issue again!
Now my plugin requires >94.0.0
But you prevent that by using ~> instead of >

Can you please change that?
That s a big issue for me as i again can't update my plugin.
Thanks

EDIT: i know you have a release on the way. Would love to see that in. Otherwise i am stuck until next version :s

[rosen-vladimirov]

Hey @farfromrefug ,
You can use the overridePods flag inside <project dir>/nsconfig.json. When this flag is enabled all pods that are declared inside App_Resources/iOS/Podfile will override the requirements for this pods inside the plugins.
In your case, in the application that's using the mentioned plugin, you can set the overridePods in nsconfig.json:

{
  "overridePods": true
}

And declare the version in the application's Podfile:

pod 'MaterialComponents/Tabs', '> 94.0'

Does this resolve your issue?

[farfromrefug]

@rosen-vladimirov sorry but it does not. My issue is with my plugin nativescript-material-components. I can't ask y users to override the Podfile. Plus they would have to override all their plugins pod versions

[rosen-vladimirov]

Hey @farfromrefug ,
Just to clarify the concept of overriding the Podfiles - CLI will still merge all Podfiles from plugins. After that it will check all of the pods defined in the App_Resources/iOS/Podfile and if there are is than one occurrence of each of them, CLI will keep in the merged Podfile only the one from the App_Resources/iOS/Podfile. All pods, which are not set in the application's Podfile will not be touched and will remain in the merged Podfile.

I understand the suggested solution will not resolve your case, but it can still be used as a temporary workaround for such case.

[farfromrefug]

ok good it is good for me to develop the plugin. But indeed i can't ask my users to do that.
No chance of changing the ~> to > before your release ? ;)

[rosen-vladimirov]

Hey @farfromrefug ,
We do not want to risk by having versions with > as the new releases of material components often cause troubles and we do not want to break users' applications. So we prefer to stick with ~> range in our Podfile.
We'll try to update the version to ~>94.5 and run some tests - if it works, we can try to include it in the release.

[farfromrefug]

@rosen-vladimirov I understand. It is a bummer as it will keep happening. But i do understand!

[farfromrefug]

@rosen-vladimirov iam still thinking about this. Couldn't the best solution be to make the tab component an external plug-in? Remove it from the core. It would remove any 3rd party dependency from the core.
We could move it into my plugin

[NathanaelA]

I suggested this a while back, because having a forced pod file is a serious pain when I don't even use this module -- https://github.com/NativeScript/NativeScript/issues/8079 -- I'm all for letting Martin taking over this component and removing it from core... :grinning:

[vakrilov]

Hey @farfromrefug
I think moving the tab component into your material components library is actually not a bad idea. There are a couple of things to consider:

1. This will be a breaking change for existing apps - which means we can execute that for NS 7.0
2. Currently the tabs are integrated in the core modules and there might be work to be done in order to properly extract them. (Mainly stuff around navigation and fragments in android). It is not something that cannot be done, and we can definitely help if we go this way.
3. This of course will mean more work for you supporting the tabs

If all these points sound reasonable - I think the next step will be to open an issue with the proposal and have a dedicated discussion around how to execute there.

[farfromrefug]

@vakrilov you know i am up for it !

1. i get it. Any planning release date? I hope we can still "upgrade" the pod version is the next release
2. Actually seems like a good thing. It means some kind of abstraction which means more plugins can use it.
3. I am up for it. And i might not be too wrong in saying that at one point in time it might be good for you guys to take ownership of the plugin anyway.

I say go!

[farfromrefug]

@vakrilov I would like this to be handled for NS7. I mean i again stuck with a pretty old version of ios material components because of this

[farfromrefug]

@vakrilov i released nativescript-material-tabs yesterday. It is a bare copy of the N tabs component so it uses the exact same API.
Now TabStrip and TabItem remain in N because of the bottomnavigation.
Maybe this should move out too.

I think it woul be best to reopen that issue. Also would need some guidance from the N ui team to make sure we go the right way on moving everything that needs to be moved out. And also to make sure all bug fixes are done in the plugin now.
A message should be added in the next minor version to tell users to start migration. Will make the 7 move easier