You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
@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.
@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.
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:
@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
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.
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 ? ;)
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.
@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
Reacted by Nathanael Anderson and Alexander 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:
This will be a breaking change for existing apps - which means we can execute that for NS 7.0
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.
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.
@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
Activity
MartoYankov commentedon Oct 10, 2019
@farfromrefug We are using the
MDCTabBarcomponent 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 componentMDCTabBarViewthat 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 commentedon Oct 10, 2019
@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-componentswill face it.MartoYankov commentedon Oct 10, 2019
@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 commentedon Oct 10, 2019
@MartoYankov You mean migrating to
MDCTabBarView? But yes would be great to get above91.0.0Tahnks again!
MartoYankov commentedon Oct 10, 2019
@farfromrefug No, the MDCTabBar is deprecated, but not yet deleted in latest.
farfromrefug commentedon Dec 6, 2019
@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 commentedon Dec 6, 2019
Hey @farfromrefug ,
You can use the
overridePodsflag inside<project dir>/nsconfig.json. When this flag is enabled all pods that are declared insideApp_Resources/iOS/Podfilewill 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
overridePodsin nsconfig.json:{ "overridePods": true }And declare the version in the application's Podfile:
Does this resolve your issue?
farfromrefug commentedon Dec 6, 2019
@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 versionsrosen-vladimirov commentedon Dec 6, 2019
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/Podfileand if there are is than one occurrence of each of them, CLI will keep in the merged Podfile only the one from theApp_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 commentedon Dec 6, 2019
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 commentedon Dec 6, 2019
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.5and run some tests - if it works, we can try to include it in the release.farfromrefug commentedon Dec 6, 2019
@rosen-vladimirov I understand. It is a bummer as it will keep happening. But i do understand!
farfromrefug commentedon Dec 6, 2019
@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 commentedon Dec 6, 2019
vakrilov commentedon Dec 9, 2019
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:
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 commentedon Dec 9, 2019
@vakrilov you know i am up for it !
I say go!
farfromrefug commentedon Apr 13, 2020
@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 commentedon Apr 15, 2020
@vakrilov i released
nativescript-material-tabsyesterday. 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