Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Convert to classes and add suitenames attributes #61
Convert to classes and add suitenames attributes #61
Changes from 1 commit
9f3b9c8
af8bcaf
62793ca
ea27a99
ac308fa
5ebe11d
c405574
19ac2bf
934d355
d13908a
ada9e92
2161361
a84446b
2be8b1b
ebd06f4
45e59f1
848a18f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Would it be possible to run a type check for all files with
@ts-check
on CI somehow? It would be neat.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 this can be done with typescript, but at that point may as well convert it all to typescript anyway as I don't think there's limits to the types we can define in JSDOC
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.
Are changes like this one completely backwards-compatible, or do they require adding curly brackets to the import statements (like this
var { Builder } = require('./builder');
)?If they break backwards-compatibility, are they necessary? Best practice?
It might maybe be safe to assume that everyone uses (and can continue to use) this as the only import?
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.
Outside of
src/index.js
this won't have any affect asrequire('junit-report-builder')
get's the default export of that file, not these files I refactored, because it resolves to the main field inpackage.json
.Technically they are breaking changes if someone does
require('junit-report-builder/src/builder')
then it will break, but technically we're not supposed to do that with node_modules 😂.That said, this is a habit of mine - doing exports like this makes sure that we use the same name everywhere or explicitly rename it.