Skip to content

MaterialComponents pod version #7928

Closed

Description

@farfromrefug

in {N} 6 your require MaterialComponents at a specific version:

pod 'MaterialComponents/Tabs', '~> 84.4'

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

Activity

  1. MartoYankov commented on Oct 10, 2019

    @MartoYankov
    Contributor

    @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.

  2. farfromrefug commented on Oct 10, 2019

    @farfromrefug
    CollaboratorAuthor

    @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.

  3. MartoYankov commented on Oct 10, 2019

    @MartoYankov
    Contributor

    @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?

  4. farfromrefug commented on Oct 10, 2019

    @farfromrefug
    CollaboratorAuthor

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

    Tahnks again!

  5. MartoYankov commented on Oct 10, 2019

    @MartoYankov
    Contributor

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

  6. farfromrefug commented on Dec 6, 2019

    @farfromrefug
    CollaboratorAuthor

    @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

  7. rosen-vladimirov commented on Dec 6, 2019

    @rosen-vladimirov
    Contributor

    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?

  8. farfromrefug commented on Dec 6, 2019

    @farfromrefug
    CollaboratorAuthor

    @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

  9. rosen-vladimirov commented on Dec 6, 2019

    @rosen-vladimirov
    Contributor

    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.

  10. farfromrefug commented on Dec 6, 2019

    @farfromrefug
    CollaboratorAuthor

    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 ? ;)

  11. rosen-vladimirov commented on Dec 6, 2019

    @rosen-vladimirov
    Contributor

    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.

  12. farfromrefug commented on Dec 6, 2019

    @farfromrefug
    CollaboratorAuthor

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

  13. farfromrefug commented on Dec 6, 2019

    @farfromrefug
    CollaboratorAuthor

    @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

  14. NathanaelA commented on Dec 6, 2019

    @NathanaelA
  15. vakrilov commented on Dec 9, 2019

    @vakrilov
    Contributor

    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.

  16. farfromrefug commented on Dec 9, 2019

    @farfromrefug
    CollaboratorAuthor

    @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!

  17. farfromrefug commented on Apr 13, 2020

    @farfromrefug
    CollaboratorAuthor

    @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

  18. farfromrefug commented on Apr 15, 2020

    @farfromrefug
    CollaboratorAuthor

    @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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions