Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add support for typescript with jsdoc #568

Closed
wants to merge 5 commits into from

Conversation

hugomrdias
Copy link
Member

@hugomrdias hugomrdias commented Jun 2, 2020

Changes

  • new eslint jsdoc plugin
  • add ts cmd with 'check', 'types', 'types-clean', 'docs' modes

Modes:

  • check checks src and test folders for ts errors
  • types generates types declarations inline with the source files
  • types-clean deletes all the *.d.ts files
  • docs generates documentation based on the type declarations

BREAKING CHANGE: The new jsdoc linter plugin can create new errors!

If we go we this, we still need to swap current documentation with this and add types generation to release cmd.

This PR does not support full typescript projects! This is only for javascript with jsdoc generated types declarations.

- new eslint jsdoc plugin
- add ts cmd with 'check', 'types', 'types-clean', 'docs' modes

Modes:
- `check` checks src and test folders for ts errors
- `types` generates types declarations inline with the source files
- `type-clean` deletes all the *.d.ts files
- `docs` generates documentation based on the type declarations

BREAKING CHANGE: The new jsdoc linter plugin can create new errors!
Copy link
Member

@vasco-santos vasco-santos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hugomrdias can you sync this work with ChainSafe/js-libp2p-gossipsub#77? I would like to not go on different paths here.

cc @wemeetagain

@hugomrdias
Copy link
Member Author

@hugomrdias can you sync this work with ChainSafe/js-libp2p-gossipsub#77? I would like to not go on different paths here.

cc @wemeetagain

That's a complete rewrite in ts and not what we want to do with the others repos. Check ipfs/js-ipfs#2945

@vasco-santos
Copy link
Member

@hugomrdias can you sync this work with ChainSafe/js-libp2p-gossipsub#77? I would like to not go on different paths here.
cc @wemeetagain

That's a complete rewrite in ts and not what we want to do with the others repos. Check ipfs/js-ipfs#2945

What is the reasoning for aegir not supporting things like linting here? I think that we can get to a solution that fits both needs with this. Moreover, I think we should try to leverage the document generation feature that aegir is providing for typescript projects

@hugomrdias
Copy link
Member Author

What is the reasoning for aegir not supporting things like linting here?

What do you mean ? linting specific for typescript ?

Moreover, I think we should try to leverage the document generation feature that aegir is providing for typescript projects

Do you mean the current one ? or the one in this PR using typedoc ?

@vasco-santos
Copy link
Member

What is the reasoning for aegir not supporting things like linting here?

What do you mean ? linting specific for typescript ?

I mean that if aegir supports typescript, for example aegir lint should work for a project like gossipsub. The current PR for gossipsub is moving away from aegir lint, but using the remaining aegir scripts. Ideally, I think that aegir should support this in the context of this PR.

Moreover, I think we should try to leverage the document generation feature that aegir is providing for typescript projects

Do you mean the current one ? or the one in this PR using typedoc ?

I mean this new feature in this PR. I don't want to move gossipsub with a a typescript decision now and later on decide that we want to make things differently to have the automated docs, if we are currently doing both work streams. So, I would like that we see if aegir can support these projects in the basic things now rather than later. If this introduces more complexity now, we can skip it! But at least, I think that it should be considered in this scope.

@hugomrdias hugomrdias changed the title feat: add support for typescript feat: add support for typescript with jsdoc Jun 2, 2020
@hugomrdias
Copy link
Member Author

This PR adds support for typescript in the scope of this issue ipfs/js-ipfs#2945 not for full typescript projects.
I updated the description of this PR to be more clear about the scope.

Mixing support for jsdoc type declarations and full typescript projects would be a giant mess.

To implement full ts support we would need another command and another eslint config that would be selected in the lint cmd.

@vasco-santos
Copy link
Member

This PR adds support for typescript in the scope of this issue ipfs/js-ipfs#2945 not for full typescript projects.
I updated the description of this PR to be more clear about the scope.

Mixing support for jsdoc type declarations and full typescript projects would be a giant mess.

To implement full ts support we would need another command and another eslint config that would be selected in the lint cmd.

Got it. I am still wondering if we should go on the same way on libp2p-gossipsub instead of moving to a minimal typescript version. This was my main goal for raising this, but the conversation moved on a different direction with the description not being clear. But it is @wemeetagain call to decide if going with a minimal typescript version has advantages

@hugomrdias hugomrdias requested a review from Gozala June 3, 2020 16:12

const EPILOG = `
Presets:
\`check\` Checks src and test folders for Typescript errors
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this mean we have to include TS comments on all of our tests?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it works as is but it may output errors for some inferred types or defined types in the source code.
Checking the tests enables us to be the users of our own types and be able to identify issues in the types early.

src/utils.js Outdated Show resolved Hide resolved
@@ -112,7 +97,7 @@ exports.getPathToNodeModules = () => {
/**
* Get the config for Listr.
*
* @returns {Object}
* @returns {object}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why has Object changed to object? Is Object not the type?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@achingbrain achingbrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Questions inline..

@achingbrain
Copy link
Member

What is left to do on this PR?

@hugomrdias
Copy link
Member Author

Nothing its good, just needs to be integrated with the others cmds, by itself its done.

we still need to swap current documentation with this and add types generation to release cmd.

package.json Outdated Show resolved Hide resolved
}

const check = async (forwardOptions) => {
const configPath = fromRoot('tsconfig-check.json')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better to fail if there is no tsconfig.json (which can include single extends directive e.g. { "extends": "aegir/src/config/aegir-tsconfig.json"}) than do this. Otherwise we introduce another instance of other tools like vscode making different assumptions than tools than aegir.

@Gozala
Copy link
Contributor

Gozala commented Sep 14, 2020

@achingbrain @hugomrdias can I land this, so I could integrate it into ipfs/js-ipfs#3281 ? I think I would want to make some additional changes too, like the ones @Xmader has suggested, because I did run into all those in the mentioned pull. @hugomrdias should I just take over this, or would you rather have me do another pull that builds upon this ?

Gozala added a commit to ipfs/eslint-config-ipfs that referenced this pull request Sep 14, 2020
@hugomrdias
Copy link
Member Author

@Gozala just take over this PR or make a new whatever is best to land easy and stable support to ts jsdocs. You already know my main concerns around this topic so just go for it.

Co-authored-by: Xmader <xmader@outlook.com>
@Gozala
Copy link
Contributor

Gozala commented Sep 15, 2020

So this pull request does following things

  1. ESLint changes (which got superseded by feat: factor eslint config to eslint-config-ipfs #638)
  2. Typedefs generation (also pursued by feat: generate ts types #637)
  3. Docs generation
  4. Type checking

I'll do the the 2nd under #637 and split this up into separate pulls for 3 and 4.

@hugomrdias hugomrdias mentioned this pull request Nov 12, 2020
@hugomrdias hugomrdias deleted the feat/typescript-support branch February 23, 2021 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants