feat: Publish TypeScript definitions

[dplewis]

Pull Request

• Report security issues confidentially.
• Any contribution is under this license.
• Link this pull request to an issue.

Issue

Closes: #2012
Closes: #2044
Closes: #1368

Approach

• Publish all files in /types.
• Publish main type definition file.
• Prevent publishing type definition tests
• Remove reference to @types/parse

[parse-github-assistant]

🚀 Thanks for opening this pull request!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (8e9750d) to head (8707110).
Report is 12 commits behind head on alpha.

Additional details and impacted files

@@            Coverage Diff            @@
##             alpha     #2491   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           64        64           
  Lines         6244      6244           
  Branches      1456      1456           
=========================================
  Hits          6244      6244           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[parseplatformorg]

🎉 This change has been released in version 6.1.0-alpha.3

[parseplatformorg]

🎉 This change has been released in version 6.1.0

[Moumouls]

hi @dplewis @mtrezza i think we have an issue here

Published types seems to be JS docs but it leads TS expect true types. also i don't know how @types/parse was managed but if generated types here are different than @types/parse, it could be a breaking change for developers using typescript.

After an upgrade to parse v6 and removing @types/parse on our monorepo, we have many failures

It seems that only documentation types are supported in TS files, not JSDoc types:

Only documentation tags are supported in TypeScript files. The rest of the tags are only supported in JavaScript files.

https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html

[Moumouls]

 error TS2694: Namespace 'Parse.Cloud' has no exported member 'BeforeFindRequest'.

113     request: Parse.Cloud.BeforeFindRequest,
                             ~~~~~~~~~~~~~~~~~

error TS2694: Namespace 'Parse.Cloud' has no exported member 'BeforeFindRequest'.

134        request: Parse.Cloud.BeforeFindRequest,
                                ~~~~~~~~~~~~~~~~~

 error TS2694: Namespace 'Parse.Cloud' has no exported member 'BeforeSaveRequest'.

156        request: Parse.Cloud.BeforeSaveRequest,
                                ~~~~~~~~~~~~~~~~~

[Moumouls]

Or i maybe missed something, i checked parse definition in parse-server, it seems that parse.cloud is not extended on parse-server new type defs

[mtrezza]

Hm, are these just a few missing types maybe? I couldn't find BeforeSaveRequest in JS or Parse Server repo. If it's just these missing types I guess it may be easy to fix?

[Moumouls]

humm there is missing types and also it seems to have conflicts with @types/parse, for TS users the update done here is quite a breaking change, because:

• Types from @types/parse are missing
• And @types/parse and types here have a conflicting signature

So it will force developpers to downgrade and stay on parse v5 until a fix is done.

I'm juste curious why we don't just take types from @types/parse here, then progressively we resolve types conflicts and type coverage from js docs etc....

I'm suggestion to copy/parse types of @types/parse for an easier migration for TS developers from v5 to v6, then we will see how we can "auto generate" types from js doc or other systme @mtrezza

[mtrezza]

My understanding was that we already figured that out and start to use our auto-generated types since we gained some coverage. With our codebase as the source of truth, we can gradually improve the types. If types are missing, we can add them over time. But you are saying that there are existing types that are different from @types/parse? Could you give an example?

[Moumouls]

I saw some signature issues yes (like on @types/parse, it undefined | string, and on parse it's just string for example.

So this kind of conflicts will prevent user upgrading to parse v6 if they use @types/parse extensively (like cloud triggers definitions)

May be here we just need to check @types/parse and add all missing triggers (i believe it's mostly types used on Cloud Functions/Cloud hooks/server stuff)

[dplewis]

@Moumouls I’ll do a PR to add the Cloud definitions to the server shortly. Also 95% of all definitions from @types/parse are included in the SDK. I always assumed that @types/parse would take precedence over the SDK if both were installed so there would be no conflicts

[Moumouls]

You are right @dplewis on type precedence, but it turns weird when on deeper level than 1 like:

• Package A (use v5 and depends on @types)
• You project (use v6 without @types )
  • project install package A

TS will resolve types or "v6" for package A ( TS WILL NOT use the types from @types/parse, if package "parse" with types exist at package A level) so TS try to merge some types but sometimes it could fail

This kind of issue can mostly happen in monorepo projects.

I recently sent a PR to patch @types/shelljs on DefinitelyTyped for a similar issue

Migrating Cloud types to "parse" should allow then users to upgrade to v6 without losing Cloud Types, 🚀