search

synacor / preact-i18n

Simple localization for Preact.
BSD 3-Clause "New" or "Revised" License
206 stars 18 forks source link

Support Preact X #33

Closed pl12133 closed 5 years ago

pl12133 commented 5 years ago

I started this before I realized #32 was in progress, but now my branch is a little ahead anyways.

Depends on https://github.com/developit/preact-jsx-chai/pull/69 for tests to pass.

billneff79 commented 5 years ago

Code looks decent. Any thoughts on release/maintenance strategies given that most projects in the wild are going to be on Preact < X for a long time to come?

ltetzlaff commented 5 years ago

For preact-router they just bumped major, so I guess this would also work here? https://github.com/preactjs/preact-router/releases/tag/3.0.0

filoozom commented 5 years ago

By the way, I just released https://www.npmjs.com/package/preact-localization, which is heavily inspired of preact-i18n but is compatible with Preact X and uses createContext instead of the legacy API. It's less featured because I'm not sure if I can do nested providers with createContext yet, but I'll look into it. That's also the reason why it's not a Pull Request.

I'm not sure how all of this is supposed to work for licensing, do you have any idea @billneff79? A lot of code changed, but some of it is basically the same.

pl12133 commented 5 years ago

Code looks decent. Any thoughts on release/maintenance strategies given that most projects in the wild are going to be on Preact < X for a long time to come?

@billneff79 I think on NPM we can publish under the next tag for PreactX packages, and wait until the stable release to publish next as latest.

billneff79 commented 5 years ago

@filoozom re: preact-localization, if the only reason you published it was to support preact X, we'll make sure we find a way to do that in preact-i18n proper. If you have another reason, then it is fine, but you need to update your license in the product github repo to be compliant with our current BSD-3 license (the copyright for Synacor needs to occur in occur in your repo - read the license file for more details).

billneff79 commented 5 years ago

@pl12133 Re release strategy, I like using a non-latest tag in npm. I think that it is going to take a long time for Preact X to be mainstream, so I'm also hesitant to make the master branch in github be Preact X by default. What do you think about this as a generic strategy:

  1. Have a preact-x branch in github that contains current preact X compatible code for the repo, and continue to use master branch as < Preact X compatibility
  2. Publish preact-x branch to the preactx tag in npm. I like that over next to disambiguate what it is for
  3. We update the README to make it clear to users of the package which branch/npm tag to use for which version of preact they are using. We would publish a patch to the existing tag on master with this readme change.
  4. If/when Preact X gains widespread adoption, we merge the preact-x branch into master on GitHub and publish it to a new major version of the latest tag on npm.
billneff79 commented 5 years ago

I pushed the changes, along with removing the requirement of preact-jsx-chai so tests would pass, to the preactX branch in this repo.

I have published version 2.0.0-preactx.2 under the preactx tag in npm. I also updated the readme with info on preact version support

This should be all set now. Any future changes to support preact X should be done on the preactX branch until it becomes widely adopted.