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/types: add main and types fields #823

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

cncolder
Copy link

  • generate type difinition files
  • tsdx is requireable now
    • so user can put TsdxOptions into tsdx.config.js JSDoc

@vercel
Copy link

vercel bot commented Aug 23, 2020

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/formium/tsdx/l67cmftp5
✅ Preview: https://tsdx-git-types.formium.vercel.app

Copy link
Collaborator

@agilgur5 agilgur5 left a comment

Choose a reason for hiding this comment

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

This exposes a lot of private APIs that it definitely shouldn't. If you'd like to use TsdxOptions, should use an external typing for it instead of exposing private APIs.

I'm also not sure exposing TsdxOptions itself is that great of an idea given that there's a big warning about how brittle tsdx.config.js is.

Also this isn't a fix, there wasn't anything broken, this is a feature

package.json Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
@agilgur5 agilgur5 changed the title (fix/types): add main and types fields (#822) feat/types: add main and types fields (#822) Aug 23, 2020
@agilgur5 agilgur5 changed the title feat/types: add main and types fields (#822) feat/types: add main and types fields Aug 23, 2020
@cncolder
Copy link
Author

cncolder commented Aug 23, 2020

I copy TsdxOptions into externalTypes.ts. So user cannot explore more types in editor. e.g. Cmd+Click in vscode.

Update comments to JSDoc. So comments will emit into externalTypes.d.ts

I'm not sure if we need exclude another .d.ts files from npm. I wish leave there. It's cool if someone find code suggestions when require('tsdx/dist/createJestConfig')

截屏2020-08-23 17 39 54

Copy link
Collaborator

@agilgur5 agilgur5 left a comment

Choose a reason for hiding this comment

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

Great work @cncolder! JSDoc comments are definitely nice to have. I think the functional changes are mostly good now and just some improvements to be made now.

Outside of the comments below, there's some other changes that should be made along with this:

  1. updating the tsdx.config.js example in the REAMDE to use imports and JSDoc types. Also replace the TsdxOptions snippet there to a link to the typing file
  2. updating the integration tests to use imports and JSDoc types

Also had a question on the imports. You took a type out of Rollup in #822 -- did you have to install Rollup directly as a devDep for that or did it work as a transitive dep? Was also thinking it might be better to export a TSDX type of the Rollup config since we could infer more

tsconfig.json Show resolved Hide resolved
src/externalTypes.ts Outdated Show resolved Hide resolved
@cncolder
Copy link
Author

So now. What's your favor @agilgur5 ?

  1. Active "declaration" in tsconfig.json. Then re-export TsdxOptions from types.ts.
  2. Disable "declaration". And add a new file to npm like types/index.d.ts. But we still need main field in package.json

Copy link
Collaborator

@agilgur5 agilgur5 left a comment

Choose a reason for hiding this comment

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

So now. What's your favor @agilgur5 ?

Yep that's the question I had when I was reviewing too. I'm not sure, probably fine with either. The public API is the same either way. Rollup itself uses 2 to simplify the API

@@ -1,8 +1,14 @@
/* eslint-disable-next-line no-unused-vars */
Copy link
Collaborator

Choose a reason for hiding this comment

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

should add this to the example in the README too since they both use tsdx lint

Copy link
Author

Choose a reason for hiding this comment

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

tsdx lint will skip tsdx.config.js

README.md Show resolved Hide resolved
src/externalTypes.ts Outdated Show resolved Hide resolved
transpileOnly?: boolean;
}

export { RollupOptions } from 'rollup';
Copy link
Collaborator

@agilgur5 agilgur5 Aug 30, 2020

Choose a reason for hiding this comment

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

I was thinking of using the exact type that TSDX modifies this to, although that may not be possible to override

Copy link
Collaborator

Choose a reason for hiding this comment

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

Nevermind, TSDX itself uses RollupOptions internally.

Copy link
Collaborator

Choose a reason for hiding this comment

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

So I ran tsc over a tsdx.config.js with the proper import and a // @ts-check and allowJs: "true" etc and that actually failed because of the lack of exact typing. E.g.:

$ tsc --noEmit
tsdx.config.js:13:5 - error TS2532: Object is possibly 'undefined'.

13     config.plugins.push(

Now the problem is that I'm not entirely sure how to do this in TS or if it's possible to. TSDX's Rollup config should conform to RollupOptions but should also be more specific than RollupOptions -- e.g. we should know that config.plugins.push is possible without any type-casting.

Of course, TSDX Rollup config could have its own interface that extends RollupOptions, but that would be the naive route and could still cause users some type-checking problems. The config is complex enough that I'd like it to be inferred (especially the plugins' types, since users may override them) while still conforming to RollupOptions (so we don't get problems like #371 ). I'm not sure if that's possible in TS or if I just haven't been able to figure out how to do it in TS.

Copy link
Collaborator

@agilgur5 agilgur5 left a comment

Choose a reason for hiding this comment

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

I'm working on a refactor of some of the types, and in the process seem to have found a better usage

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
transpileOnly?: boolean;
}

export { RollupOptions } from 'rollup';
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nevermind, TSDX itself uses RollupOptions internally.

- generate type difinition files
- tsdx is requireable now
  - so user can put `TsdxOptions` into tsdx.config.js JSDoc
- copy TsdxOptions to externalTypes.ts
  - so user cannot explore another types
- use typings field same as basic template
- use JSDoc comments
  - so it will emit into externalTypes.d.ts
- update readme tsdx config example
- update integration test fixtures
- re-export options type
- update types comment to JSDoc
- update readme options point to source code file
- remove main field from package.json
- update integration test fixtures
- update readme example
Copy link
Collaborator

@agilgur5 agilgur5 left a comment

Choose a reason for hiding this comment

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

Thanks for all the iterations despite the long wait in between! I think this is close to complete, but I've found more issues as I've dug into it and tried more myself 😐 . This is definitely useful for tsdx.config.js users!

I could take this over completing this myself now though (you'd of course be credited regardless for this work!), especially as some of these issues likely require some internal typing refactoring (which I've already started too), but if you know more about some TS nuances in the comments, that could be quite helpful!

transpileOnly?: boolean;
}

export { RollupOptions } from 'rollup';
Copy link
Collaborator

Choose a reason for hiding this comment

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

So I ran tsc over a tsdx.config.js with the proper import and a // @ts-check and allowJs: "true" etc and that actually failed because of the lack of exact typing. E.g.:

$ tsc --noEmit
tsdx.config.js:13:5 - error TS2532: Object is possibly 'undefined'.

13     config.plugins.push(

Now the problem is that I'm not entirely sure how to do this in TS or if it's possible to. TSDX's Rollup config should conform to RollupOptions but should also be more specific than RollupOptions -- e.g. we should know that config.plugins.push is possible without any type-casting.

Of course, TSDX Rollup config could have its own interface that extends RollupOptions, but that would be the naive route and could still cause users some type-checking problems. The config is complex enough that I'd like it to be inferred (especially the plugins' types, since users may override them) while still conforming to RollupOptions (so we don't get problems like #371 ). I'm not sure if that's possible in TS or if I just haven't been able to figure out how to do it in TS.

Comment on lines +7 to +8
* @param {import('tsdx').RollupOptions} config
* @param {import('tsdx').TsdxOptions} options
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* @param {import('tsdx').RollupOptions} config
* @param {import('tsdx').TsdxOptions} options
* @param {import('../../../../').RollupOptions} config
* @param {import('../../../../').TsdxOptions} options

You had require('..') before, so it should either be that ('..') or this, which works in VSCode but may not work during the test phase where this gets moved to the "staging" dir. But tsdx build can't type-check this anyway (otherwise we'd be using tsdx.config.ts). Might add tsc tests in the future for things like #871 though...

@@ -3,6 +3,10 @@ const autoprefixer = require('autoprefixer');
const cssnano = require('cssnano');
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can't comment at the top of the file, but per my other comment, we probably want to add // @ts-check to the top of this and the example file.

Adding allowJs + checkJs to templates' and the tests' tsconfig probably makes more sense long-term, but there will probably be some ramifications to that and may want to wait to do that until #871 is fixed and creates two tsconfigs, one for build and one for type-checking. I definitely need to test that more before adding.

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.

Add TSDX's own typedefs in order to use in tsdx.config.js with JSDoc
2 participants