3 ms·

I understand Semver, but then I'd get no new updates and for no good reason. It doesn't make any sense to remove it.

afavour 4y ago
They'd be able to publish updates to older versions of the library if they so wished. Like v2.6.0 -> v3.0.0 deprecates _.fill(), then a security fix comes along so they publish 3.0.1 2.6.1 > It doesn't make any sense to remove it. It does. Once the native platform supports the functionality it's redundant to keep it around and makes it less clear to a developer that the library isn't required any more. I'd argue it doesn't make any sense to use it but I'm not going to tell you that you can't. It's possible to accommodate everyone.
- nightski 4y ago
  They'd be able to, but they won't. I disagree. Keeping it in accommodates everyone (not just your needs). You are not forced to use it, or even bundle it. I use lodash-es w/ tree shaking as it is.
  - afavour 4y ago
    > They'd be able to, but they won't. Why not? Until recently they were publishing individual packages for every single Lodash function. Publishing different versions that just do or do not exclude a single function is pretty simple by comparison. It seems like you want the project to hold itself back for no good reason.
    - deleted 4y ago
      [deleted]
    - nightski 4y ago
      Having to maintain older versions because you pulled out a function is much more burdensome than just keeping it in. I prefer the lodash way of doing things, you don't. So don't use it, that is fine.
      - afavour 4y ago
        > Having to maintain older versions because you pulled out a function is much more burdensome than just keeping it in. Right. But we're talking about group that until recently maintained 281 separate packages. "much more burdensome" is a relative term here and publishing two versions simultaneously is absolutely not that burdensome. > I prefer the lodash way of doing things, you don't. So don't use it, that is fine. The solution I'm proposing lets you and me both use it exactly how we want to. I honestly find this debate to be quite baffling.

They'd be able to publish updates to older versions of the library if they so wished. Like v2.6.0 -> v3.0.0 deprecates _.fill(), then a security fix comes along so they publish 3.0.1 2.6.1 > It doesn't make any sense to remove it. It does. Once the native platform supports the functionality it's redundant to keep it around and makes it less clear to a developer that the library isn't required any more. I'd argue it doesn't make any sense to use it but I'm not going to tell you that you can't. It's possible to accommodate everyone.

nightski 4y ago
They'd be able to, but they won't. I disagree. Keeping it in accommodates everyone (not just your needs). You are not forced to use it, or even bundle it. I use lodash-es w/ tree shaking as it is.
- afavour 4y ago
  > They'd be able to, but they won't. Why not? Until recently they were publishing individual packages for every single Lodash function. Publishing different versions that just do or do not exclude a single function is pretty simple by comparison. It seems like you want the project to hold itself back for no good reason.
  - deleted 4y ago
    [deleted]
  - nightski 4y ago
    Having to maintain older versions because you pulled out a function is much more burdensome than just keeping it in. I prefer the lodash way of doing things, you don't. So don't use it, that is fine.
    - afavour 4y ago
      > Having to maintain older versions because you pulled out a function is much more burdensome than just keeping it in. Right. But we're talking about group that until recently maintained 281 separate packages. "much more burdensome" is a relative term here and publishing two versions simultaneously is absolutely not that burdensome. > I prefer the lodash way of doing things, you don't. So don't use it, that is fine. The solution I'm proposing lets you and me both use it exactly how we want to. I honestly find this debate to be quite baffling.