-
Notifications
You must be signed in to change notification settings - Fork 4
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
Link to unpkg.com #20
base: main
Are you sure you want to change the base?
Conversation
…show the npm package-relative path
}); | ||
const { UnpkgPlugin } = require('./UnpkgPluginImpl'); | ||
|
||
module.exports = function (PluginHost) { |
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.
Nooooooooooo
module.exports =
style plugins are deprecated, useexports.load = function
instead- PluginHost is dead. Plugins are now passed an
Application
instance addComponent
is going to go away. The whole idea of components overcomplicates everything. Plugins should never have used the@Component
decorator.
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, this was copy-pasted from https://github.com/gdelmas/typedoc-plugin-sourcefile-url
|
||
private onBegin(): void { | ||
// register handler | ||
this.listenTo(this.owner, Converter.EVENT_RESOLVE_END, this.onEndResolve); |
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.
Why is the event registration split up?
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.
Same reason as above, it was copy-pasted from https://github.com/gdelmas/typedoc-plugin-sourcefile-url
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.
Vague takeaways for me:
- @Gerrit0 will be punished in the afterlife for using classes and decorators
- plugin stuff mostly looks greek to me, but at least the non-boilerplate looks pretty short
- Odds are good that sticking with ESM will lead to more of these little pain points. My experience with node in general is that CJS is that path of least resistance. On the other hand, let me know if there's some compelling tangible benefit to using ESM in this project, I might just be unaware.
It wasn't me! Blame Sebastian. I've been slowly removing them... |
Decorators are fine and have their uses but this is definitely not one of them. Agreed about CJS vs ESM. I always recommend that users do everything with CJS instead of ESM, but I wanted to give it a try so I'd have some first-hand experience, since I have to design features for ESM users in One potential benefit of ESM: If we use more of Sindre's open-source stuff then we might eventually hit one that's been recently updated to ESM, since he's been doing that to all his libraries. |
Closes #6
"Declared in" links go to unpkg.com
Accomplished via a typedoc plugin. Plugin is not precompiled; ts-node bootstrapper avoids precompilation. We should definitely precompile once the plugin feels "finished" because loading ts-node for every typedoc invocation is gonna slow things down.
I also had to do some boilerplate so that the plugin runs as CommonJS, since typedoc cannot load ESM plugins.
There are some other trivial changes in this PR that I didn't explain out of laziness, but let me know if you want a description of any of them.