Upgrade browserify

[vweevers]

Continuing from #165 (comment):

Just some additional context: browserify 14 was released in Jan 2017 (~1.5 years ago) and IE9 and IE10 haven't been supported in browserify since then. Perhaps it's still too early to drop support in other libraries (which manage to avoid using buffer)

However, I'm curious when folks will feel comfortable dropping support, and what the criteria will be for knowing that it's time?

[ralphtheninja]

Just had an idea. We could finish off v1.0.0 on airtap and once that's done, we can upgrade browserify to the latest version and bump major version again.

This way you can stay on airtap@1.x if you really care about IE9-10 (and we can offer support in form of patches, just not bumping browserify) and if you don't care you use airtap@2.x.

It also enables us to postpone the decision of dropping IE9-10 support a little further.

[goto-bus-stop]

https://github.com/airtap/airtap/blob/master/doc/airtap.yml.md#browserify-optional

Seems like doing

npm install -D buffer@4

browserify:
  - require: "buffer/"
    expose: "buffer"

would allow you to use a locally installed Buffer v4 module. With a simple workaround like that I think dropping support by default is OK. I like @ralphtheninja's suggestion too—release 1.x with browserify@13 first to reduce friction for packages that are still switching from zuul to airtap, then later they can either upgrade to airtap@2 and add the workaround to get the new browserify, or stay on airtap@1 as long as it works for them.

e; Personally I'd like to support as many things as possible as long as possible, until it becomes really difficult. for many modules supporting IE9 is quite easy because it has decent ES5 support. It would be a shame to drop support for those browser versions (even if they are little used) when it's not that difficult to keep them around. Obviously for buffer there was a clear benefit to dropping support, but this is not true for many other modules.

[feross]

release 1.x with browserify@13 first to reduce friction for packages that are still switching from zuul to airtap, then later they can either upgrade to airtap@2 and add the workaround to get the new browserify, or stay on airtap@1 as long as it works for them.

I like this approach very much. 👍

[vweevers]

Yes! Let's do that.

[vweevers]

Related: I noticed that our version of watchify (~3.11.0) depends on browserify ^16.1.0. Could that cause problems?

[goto-bus-stop]

It shouldn't, watchify only depends on browserify for its CLI. since airtap uses watchify as a plugin instead it's fine.

[vweevers]

At this time, I think I prefer just dropping IE10 right away and release airtap@0.2.0. There's still a few open tasks before we can release 1.0.0, but there's no immediate need for those (airtap is working fairly well atm) but I would like to upgrade browserify. And of the projects listed in the readme and others I know about, most have dropped IE10 already, the rest (memdown, level-js, levelup) will soon follow.

[goto-bus-stop]

airtap is used in the util and events shims which both still support IE10 and will for the foreseeable future, but the workaround is easy so dropping is fine IMO.

IIRC browserify 13 doesn't support async functions and some other modern syntax features that are now sometimes used untranspiled in new modules, so there are real benefits to upgrading.

[vweevers]

airtap is used in the util and events shims which both still support IE10 and will for the foreseeable future, but the workaround is easy so dropping is fine IMO.

Ah, cool. Can you share links to those modules?

IIRC browserify 13 doesn't support async functions and some other modern syntax features that are now sometimes used untranspiled in new modules, so there are real benefits to upgrading.

💯

[goto-bus-stop]

https://github.com/defunctzombie/node-util
https://github.com/Gozala/events

[vweevers]

I see they include IE9, even. Nice to know airtap works there :)

Alternatively, we can release 1.0.0 now (without the originally planned tasks, for which I personally have no capacity atm), then upgrade browserify and release 2.0.0.

Airtap's API hasn't stabilized, so we might have to release a few more majors in succession, but that's fine as long as breaking changes are clearly documented. I also like @feross's argument that it's easier to identify a semver-major as having breaking changes.