Maintainability improvements.

[sachaw]

With the release of graphql.js v16 I came to take a look if I could contribute any fixed required to move this along.

I have noticed a few things:

• Examples dependencies, exist in the main package's package.json. Ideally the examples could have there own repo or at least be independent projects (nested src directories and individual package.json's. This is also a blocker for graphql.js v16 as a number of the examples have dependencies that are not supporting it yet.
• Still using TSLint, this was deprecated in 2020 in favor of ESLint, which has matured a great deal in recent times.
• Website source contained in the package repo, moving this to it's own repo would simplify deployment.
• Use the exports entry in package.json ro describe entry points versus the legacy main.
• Look at supporting ESModules a considerable amount of mainstream projects are moving to ESModule only as it provides a great number of benefits. https://www.typescriptlang.org/docs/handbook/esm-node.html https://medium.com/swlh/npm-new-package-json-exports-field-1a7d1f489ccf
• Move gulp tasks to GitHub actions, again, simplification.

Please take these points as some suggestions to ensure the long-term maintainability of this great package.
If you'd provide some feedback on what points you like/dislike I'd be more than happy to work on them.
P.S (I have opened a number of upstream issues to address graphql.js v16 support, some of which have already been merged).

Regards.

[MichalLytek]

1. Agree. I do this in https://github.com/MichalLytek/typegraphql-prisma already. However, with such large amount of examples, it's a nightmare to keep deps up to date. They could live in a separate repository, which is against my goal to have a proper monorepo setup with small npm packages in the future.

2. Agree, never had time to port and setup the rules. I have setup typescript eslint in my other project and every month I need to go through release notes to disable or enable some new rules. I'm open to good PRs in that matter 😉

3. No, docs and website package needs to stay in this repo. It doesn't block or break anything, works very well for me

4 and 5) ESM only is a pain in the ass, I don't support this movement. If we can have both CJS and modules at the same time, I'm also happy to review such PR 😉

6. You mean continuous deployment (or release in terms of package)? I've recently migrated with CI task from Travis.

[tomasstrejcek]

Hi @MichalLytek, wanted to finally jump in with some PRs but the current state (issues hanging, dependencies glow with bright red etc) suggest you might need help dealing with all that before shovelling my ideas into the repo, so

what I (or somebody else of course) can do to help you? Would love to have more versions with cool features than once-a-year release :)

[MichalLytek]

@tomasstrejcek There are some maintenance tasks listed above that I'm happy to see a PR for 😉

I have a really time-consuming things in my personal life now, so I can afford only basic maintenance, but I expect in the second half of the year to get back to more features-oriented work on TypeGraphQL 🙌

[tomasstrejcek]

@MichalLytek anything needed to do to be able to release the 1.2.0-rc1 as stable? In the meantime i will update all packages that doesnt require major changes and split peer deps for examples?

[MichalLytek]

On branch v16 there is a deps update which will be promoted to v2.0.0-rc1. I need to browse other breaking changes in issues (like decouple class-validator support), so we can apply them in the major release.

[tomasstrejcek]

I presume that will take some time to prepare, I believe lot of people are stuck on 1.1.1, so It might be good idea to "finalize" the v1.x branch as fully updated without tons of vulnerabilities (as reported by npm audit)?

[MichalLytek]

No because 1.1.1 contains kinda breaking changes because of deps bump and interface rename. It should be released in v2.0.

[carlocorradini]

@sachaw Started the process for better maintainability. See #1400