-
Notifications
You must be signed in to change notification settings - Fork 508
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
base: master
Are you sure you want to change the base?
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/formium/tsdx/l67cmftp5 |
There was a problem hiding this 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
I copy Update comments to JSDoc. So comments will emit into 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 |
There was a problem hiding this 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:
- updating the
tsdx.config.js
example in the REAMDE to use imports and JSDoc types. Also replace theTsdxOptions
snippet there to a link to the typing file - 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
So now. What's your favor @agilgur5 ?
|
There was a problem hiding this 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 */ |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
transpileOnly?: boolean; | ||
} | ||
|
||
export { RollupOptions } from 'rollup'; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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
transpileOnly?: boolean; | ||
} | ||
|
||
export { RollupOptions } from 'rollup'; |
There was a problem hiding this comment.
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
There was a problem hiding this 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'; |
There was a problem hiding this comment.
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.
* @param {import('tsdx').RollupOptions} config | ||
* @param {import('tsdx').TsdxOptions} options |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @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'); |
There was a problem hiding this comment.
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 tsconfig
s, one for build
and one for type-checking. I definitely need to test that more before adding.
TsdxOptions
into tsdx.config.js JSDoc