-
Notifications
You must be signed in to change notification settings - Fork 0
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
Fix up config for docs generation #16
Conversation
e384ce6
to
d361ecd
Compare
@@ -32,7 +32,7 @@ | |||
"require": "./dist/index.js", | |||
"import": "./dist/index.mjs" | |||
}, | |||
"./module": "./dist/module/index.mjs" | |||
"./error": "./dist/error.mjs" |
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.
"./error": "./dist/error.mjs" |
I don't think this makes sense. There should be only one point of export in this package.
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.
(in other words, 1 way to import things from this package)
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 is here in this, as in all of our libraries, as a way to import directly import x from "@inrupt/errors/filename"
when using ES6 modules.
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 think we need to do this as an object, so the typescript types work; there's a issue on github on another repo about this, I think solid-client-js
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.
Yeah, you'd need a typesVersions field (like the one I added to solid-client-access-grant-js).
But for such a small package, it doesn't make sense to enable a sub-module import syntax.
It might actually even be a bad idea for most larger libraries (cost/benefits) but that's not the discussion at hand here.
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.
Agree for this library sub-module imports probably doesn't make sense.
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 think it's important to maintain consistency with our other libraries - I don't see any significant "cost" to keeping this here.
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 think the kind of consistency we should work towards is applying a set of best practices in coding, one of which would be not to expose sub-modules when a package doesn't have any.
I also think that sub-modules only make sense in specific situations and I'm not sure they're curently warranted in any of our packages since they increase complexity and provide little benefit unless I'm missing something.
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 also think that sub-modules only make sense in specific situations and I'm not sure they're curently warranted in any of our packages since they increase complexity and provide little benefit unless I'm missing something.
Which is fine, but that's not a discussion for this PR. That is a separate discussion we can have as it affects all of our libraries.
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.
OK, let's schedule that discussion soon 🤞
(also because as it stands, our submodule exports are broken as missing types)
src/error.ts
Outdated
@@ -16,6 +16,9 @@ | |||
// HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION | |||
// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE | |||
// SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. | |||
|
|||
// rdfjs/types package throws linter errors | |||
// eslint-disable-next-line import/no-unresolved |
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.
That's weird, never seen that happen elsewhere, might check it out.
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.
Yeah, it's super weird. It doesn't happen in solid-client (the only library I'm aware of which is using this) because it doesn't have the dependency linter.
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'll try to look at it before we make public.
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 can be fixed using the docs here: import-js/eslint-plugin-import#1485
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 we need to fix this in our base eslint config.
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've said this before, I think that we should consider making our eslint-config-base peerDependencies non version specific (all *):
https://github.com/inrupt/javascript-style-configs/blob/c169edebb71650bd059e3bdc3fe990cb3cb008c5/eslint-config-base/package.json#L23-L34
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.
@matthieubosquet because we're using ^
versions in our peerDependencies, nothing's stopping us from updating. The eslint config only specifies a minimum, which is useful.
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.
Ok, I get that, but it makes us stuck on majors.
What about just starring the two @typescript-eslint dependencies?
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.
We do want to be on the same majors across our libraries, or as close as possible.
tsconfig.json
Outdated
@@ -69,20 +69,14 @@ | |||
// The source files of everything listed under `exports` in our package.json | |||
// (i.e. public API's that should be documented) should be listed here: | |||
"src/index.ts", | |||
"src/index.ts", | |||
"src/error.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.
"src/error.ts", |
This doesn't need to/shouldn't be here.
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.
Without this here, the docs don't generate on that file.
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.
That's because src/index.ts
is excluded on line 83/79
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.
hahaha, this config is such a mess ^^,
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.
We don't need index though, we just need error. Index just re-exports error.
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.
Looks good, but I think there's some issue still.
@@ -32,7 +32,7 @@ | |||
"require": "./dist/index.js", | |||
"import": "./dist/index.mjs" | |||
}, | |||
"./module": "./dist/module/index.mjs" | |||
"./error": "./dist/error.mjs" |
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 think we need to do this as an object, so the typescript types work; there's a issue on github on another repo about this, I think solid-client-js
tsconfig.json
Outdated
@@ -69,20 +69,14 @@ | |||
// The source files of everything listed under `exports` in our package.json | |||
// (i.e. public API's that should be documented) should be listed here: | |||
"src/index.ts", | |||
"src/index.ts", | |||
"src/error.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.
That's because src/index.ts
is excluded on line 83/79
This updates tsconfig and package.json to fix docs site generation.