2.0 release

[macobo]

Over the last months we've been adding a ton of new functionality to posthog-js and got the library under control testing-wise.

I think it's time to clear house - make the library smaller, remove things that are broken or we don't want to support any longer. However this is by definition a breaking change.

I've created a list of things I'd like to do for 2.0 release. Let me know if any of them are controversial or if you have ideas of your own.

1. ✅ Make browser support explicit - We currently support IE11 and newer -> see https://github.com/PostHog/posthog-js/pull/673
2. ✅ Replace parcel with rollup, minify - I have a WIP branch with this working, before all of the changes below it seems to reduce array.js size ~30-40% (and module.js much more as it isn't minified correctly.
3. Drop deprecated methods
4. Remove return values, callbacks from .capture calls and elsewhere
5. ✅ Remove (broken) GET and image request support, api_method and img config options - https://github.com/PostHog/posthog-js/issues/138 removed in #651
6. Remove custom overrides for console.log and others - This would remove some package size
7. ✅ Remove lz64 support along with application/x-www-form-urlencoded - after gzip support this just bloats the library. Semi-breaking change - ideally all users would update to posthog 1.19 as well when doing this update. -> remove lz64 support in https://github.com/PostHog/posthog-js/pull/654
8. Remove application/x-www-form-urlencoded - after gzip support this just bloats the library. Semi-breaking change - ideally all users would update to posthog 1.19 as well when doing this update.
9. Remove multi-instance support - One legacy feature we have is support for array.js being included multiple times. I don't think anyone has ever used this functionality or if it even works still - it might be worth dropping.
10. Remove xhr_headers config option - https://github.com/PostHog/posthog-js/issues/147
11. Drop posthog.set_config method
12. Drop posthog.capture_pageview method
13. Drop posthog.toString method
14. Drop trim polyfill, other unused polyfills https://caniuse.com/?search=trim
15. Drop upgrade config option - this seems completely dead
16. Deprecate snake_cased public methods, add camelCased alternatives

Except for packaging improvements all of this is just deleting code - should be easy to do.

We might also want to consider dropping base64 support - again, would help drop a few KB off the package.

@mariusandra I know you have opinions on the casing as well. Do you think it's time to make camelCase methods a thing? It might be too annoying of an update though - everything else above should require 0 action from users unless they're doing something weird.

cc @timgl

[mariusandra]

The list of things to drop sounds good and I have nothing from the top of my head to add.

Casing is something I'd fix. It's really weird to be inconsistent and have half of the methods be isFeatureFlagEnabled, the other half opt_out_of_capturing. Luckily the most used methods (capture, etc) are all unaffected. For the rest, I'd deprecate them with warnings starting 2.0 and eventually drop then in 3.0.

Regarding 2.0 in general, it might be cool to wait until PostHog 2.0 hits the shelves. We're at 1.19 with a bunch of cool things still in "beta" (session recording, plugins, new design). We haven't really discussed it, but it might be worth releasing a big 2.0 somewhere in the beginning of next year when all of these stabilise. Together with a big launch, removing deprecated DB fields, etc. If this happens, it might be worth aligning posthog-js version 2.0 with that.

[weyert]

Remove multi-instance support - One legacy feature we have is support for array.js being included multiple times. I don't think anyone has ever used this functionality or if it even works still - it might be worth dropping.

Does this mean things like const posthogInstance = posthog.init(props.apiKey, { ...props.options, debug: false }, name) as PosthogClient won't work anymore?

[macobo]

Thanks for the feedback @mariusandra

For the rest, I'd deprecate them with warnings starting 2.0 and eventually drop then in 3.0.

Sounds like a good plan - adding to the list.

Regarding 2.0 in general, it might be cool to wait until PostHog 2.0 hits the shelves.

That might make sense indeed, especially if we're dropping backwards compatibility for that version. I wonder though if we should then make the bundling improvements separately.

Will bring this up during the standup.

Does this mean things like const posthogInstance = posthog.init(props.apiKey, { ...props.options, debug: false }, name) as PosthogClient won't work anymore?

That will still work. There's some weird code that allows including the posthog snippet multiple times on the site and for it to continue working. There's no real usecase for this though.

[timgl]

I think we can just tackle this stuff (ex the naming changes) without waiting for any 2.0 releases. Most of these issues raised are not visible anyway.

[macobo]

The only thing really tackleable without it being a breaking posthog-js change is rollup + console.log changes.

Everything else in this list is breaking in the sense of either:

1. Removing existing methods or config options
2. Increasing minimum version of posthog (compression support removal, simplifying how we do requests)
3. Potentially breaking some older browser support (polyfills etc)

[pauldambra]

rollup support done here https://github.com/PostHog/posthog-js/pull/434