schemats
schemats copied to clipboard
SweetIQ
Project maintainance
Follow up of https://github.com/SweetIQ/schemats/issues/104#issuecomment-526201898
Some background : @xiamx the original author of this module, and @crispmark another contributor, have both left SweetIQ and can't provide maintenance anymore (see https://github.com/SweetIQ/schemats/pull/81#issuecomment-510185054).
At @Arhia (my company), we use this module everyday in a very big application and we would want this project to be maintained, so I proposed to start a fork and ensure a (at least minimal) maintenance.
Contributors will of course be welcomed.
The goal is to maintain the project and merge the potential good PR pending here.
Some questions though :
1. Organization
I created schemats organization today : https://github.com/schemats I will invite people later (I'm still learning how to manage Collaborators rights)
2. Start point for the fork
Should the repository be forked from here or from https://github.com/xiamx/schemats/ ? The latter is 12 commits ahead so I would like to start from it, @xiamx can you confirm it's a good idea ?
3. Forking or cloning
Forking keep the link with the original repository, but it's unlikely here that we will be able to merge back into SweetIQ/schemats so I would rather clone the repo, for clarity.
4. Npm
It looks like @xiamx owns npm account (see https://github.com/SweetIQ/schemats/issues/104#issuecomment-526375934) so we would be able to publish new version under the same name, providing a smooth transition.
I'd love to contribute to this new fork! I think we should compose a list of all useful forks/PR's/issues that should be transferred to the new "fork"/version.
I already have #105 and an implementation of 'lookup tables' as enums pending. While creating these contributions I noticed that the current project structure doesn't have a separate build directory, I'd love to see that changed as well (probably already have a commit for that laying around somewhere).
Also I'd suggest adding dotenv to allow for easier configuration of the POSTGRES_URL and MYSQL_URL environment variables.
Should the repository be forked from here or from https://github.com/xiamx/schemats/ ? The latter is 12 commits ahead so I would like to start from it, @xiamx can you confirm it's a good idea ?
I get the impression that @xiamx's intended for it to be a new home anyway so that'd probably work.
Forking keep the link with the original repository, but it's unlikely here that we will be able to merge back into SweetIQ/schemats so I would rather clone the repo, for clarity.
Should we change the name if we clone instead of fork to prevent confusion? I think perhaps the best possible solution would be to transfer this repository over to the new organization and go from there. This also makes merging pending material a lot easier.
Should we change the name if we clone instead of fork to prevent confusion?
You're right but all meaningful names (typedschema, etc) are already used, and if we can publish with the same name on npm, it worth keeping the name schemats for consistency.
I think perhaps the best possible solution would be to transfer this repository over to the new organization and go from there. This also makes merging pending material a lot easier.
I don't think @xiamx could easily transfer this repository, it belongs to SweetIQ company (@xiamx can you confirm ?). If it's the case, we will have to clone or to transfer https://github.com/xiamx/schemats/ to the new organization https://github.com/schemats
-
The https://github.com/xiamx/schemats/ fork is mostly url changes (
SweetIQ->xiamx), build/configuration fixes, and package updates. I think that it definitely makes sense to use that fork as the starting point. -
Echoing what has already been said, I would agree that cloning makes the most sense. It's a shame that a deprecation + link from the current repo to the new one isn't likely.
-
This is great!
I'm not sure if I would advocate for a renaming of the codebase (as it's still the same tool), but if this was necessary I would recommend a subtle change like schema-ts.
I'm not sure if I would advocate for a renaming of the codebase (as it's still the same tool), but if this was necessary I would recommend a subtle change like schema-ts.
We should probably add a section on what this "new version" is to the README if a namechange is this subtle, to make it clear that this is the new and improved (and maintained) version.
I hope @xiamx can find a way to transfer this repository so we can avoid all confusion and keep the open issues/pull requests. Merging his fork as "starting point" would be trivial.
Unfortunately I don't think transfer of repo is a possibility. All the people I worked with before from sweetiq no longer work there...
It sucks that there's no easy way to redirect traffic from this project to the new one. But if this new fork/clone fixes important bugs, then recognition and popularity will flow in eventually 😄
That's unfortunate. Of course if we can publish to npm under the same name we can easily change all links to the new organization to direct any new users to the new location. Creating an issue in this repository with a title like "look over here for fixes" would probably be enough to direct all existing users (eventually).
That still leaves the issue of transferring PR's and issues however.
I've sent an email to github support to see if they have a way to mass copy issues and pull requests to a fork. Let's see if there's a non manual repetitive way available for us.
What’s the status of this? I would like to use Schemats in projects, but I was concerned that it looked abandoned. I can assist with maintenance if needed.
What’s the status of this?
I have forket this project to https://github.com/schemats/schemats and I'm loooking how to float the pending PR to the fork.
I would like to use Schemats in projects, but I was concerned that it looked abandoned. I can assist with maintenance if needed.
At @Arhia we will maintain it anyway, we rely on it for a very big application.
In the case that PRs cannot be transferred, what would you anticipate the fallback plan to be? I suppose that any of the larger PRs could be separately forked and merged with the the new repo prior to the full divergence.
To be honest, I would be a bit surprised if there was a non-manual way to transfer issues & PRs.
To be honest, I would be a bit surprised if there was a non-manual way to transfer issues & PRs.
Yes and no. I will probably be able to recreate PR from the forks via the website. For simple branches, I will have to use command line see https://stackoverflow.com/questions/6022302/how-to-apply-unmerged-upstream-pull-requests-from-other-forks-into-my-fork
The command line probably wouldn't be necessary because you can create PR's from other people's forks (unless I'm missing something here...)
The command line probably wouldn't be necessary because you can create PR's from other people's forks (unless I'm missing something here...)
Yes, but only if there's a fork (nevertheless it should be the more common case). I began to recreate the PR, see https://github.com/schemats/schemats/pull/1
If some folks want to send the PR themselves, they can (but I don't guarantee I will have enough time to review them and merge in the short term)
If some folks want to send the PR themselves, they can (but I don't guarantee I will have enough time to review them and merge in the short term)
Maybe the folks here (and myself as well) can help contribute reviewing those.
@abenhamdine what's your npm username?
Maybe the folks here (and myself as well) can help contribute reviewing those.
Yes of course ! Let me just think about how to organize that without being overwhelmed by questions, etc...
@abenhamdine what's your npm username?
arnaudbenhamdine
@abenhamdine Is your company still planning on moving forward with this? This repo is so getting so outdated, it'll be great to see a maintained version.
@ellis yes it's still planned, but we are currently working on a major release of our product, so it's difficult to work on it, sorry.
Also @jawj made some edits to it for https://github.com/jawj/mostly-ormless - I'm keen to use that approach at my company, but the lack of support for schemats (even moreso since his fork is more likely to fall out of date) gives me cold feet to rely on this library. not familiar with the inner workings of the library but i'll read up a bit and see how i can help.
Hey everybody. I have forked this repo to https://github.com/mlogan/schematzah, upgraded all dependencies, made some tsconfig changes, switched to yarn, and pushed the result as the npm package schematzah.
I don't plan to do any development on this (I just needed a version built with a recent typescript), but I'm happy to merge PRs and publish new versions.
I know there was some discussion about moving PRs over to a new repo. I recommend just forking the new repo, pushing your commits to it, and then opening a new PR with a link back to the original PR.
That's awesome @mlogan ! I'll try to upgrade my projects!
On another note, in some of my projects I needed the schema types but in most of my projects what I really needed was types of the results of my queries... Recently I've found pgTyped which does exactly that and I must say I enjoy it a lot (and it's well maintained)
Also @jawj made some edits to it for https://github.com/jawj/mostly-ormless - I'm keen to use that approach at my company, but the lack of support for
schemats(even moreso since his fork is more likely to fall out of date) gives me cold feet to rely on this library. not familiar with the inner workings of the library but i'll read up a bit and see how i can help.
BTW @osdiab I've converted the 'mostly-ormless' approach into a new library, and I've rewritten out the dependency on this project. I'm currently writing up the documentation. It's at https://github.com/jawj/zapatos and published as zapatos on npm.
Another related successor project:
https://github.com/nettofarah/postgres-schema-ts
May also be interesting:
https://github.com/xialvjun/ts-sql-plugin
And another (much closer to this project, looks highly configurable and well-maintained):
https://github.com/rmp135/sql-ts
