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

Fix up config for docs generation #16

Merged
merged 7 commits into from
Mar 16, 2022
Merged

Fix up config for docs generation #16

merged 7 commits into from
Mar 16, 2022

Conversation

ajacksified
Copy link
Contributor

This updates tsconfig and package.json to fix docs site generation.

@ajacksified ajacksified requested a review from dgbarclay July 23, 2021 13:28
@ajacksified ajacksified marked this pull request as draft December 15, 2021 11:57
@ajacksified ajacksified removed the request for review from dgbarclay December 15, 2021 11:57
@ajacksified ajacksified marked this pull request as ready for review December 15, 2021 12:09
docs/api/Makefile Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
@@ -32,7 +32,7 @@
"require": "./dist/index.js",
"import": "./dist/index.mjs"
},
"./module": "./dist/module/index.mjs"
"./error": "./dist/error.mjs"

Choose a reason for hiding this comment

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

Suggested change
"./error": "./dist/error.mjs"

I don't think this makes sense. There should be only one point of export in this package.

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)

Copy link
Contributor Author

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.

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 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

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

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.

Copy link
Contributor Author

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.

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

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.

Copy link
Contributor Author

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.

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.

Copy link
Contributor

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

Screenshot 2021-12-15 at 19 29 29

Copy link
Contributor

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.

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

Copy link
Contributor Author

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.

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?

Copy link
Contributor Author

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",

Choose a reason for hiding this comment

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

Suggested change
"src/error.ts",

This doesn't need to/shouldn't be here.

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link

@matthieubosquet matthieubosquet Dec 15, 2021

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 ^^,

Copy link
Contributor Author

@ajacksified ajacksified Dec 17, 2021

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.

Copy link
Contributor

@ThisIsMissEm ThisIsMissEm left a 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"
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 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

package.json Show resolved Hide resolved
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",
Copy link
Contributor

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

@ajacksified ajacksified enabled auto-merge (rebase) March 16, 2022 16:47
@ThisIsMissEm ThisIsMissEm merged commit d319d8b into main Mar 16, 2022
@ThisIsMissEm ThisIsMissEm deleted the fix/docs branch March 16, 2022 16:47
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.

3 participants