Skip to content

Conversation

@pldg
Copy link
Contributor

@pldg pldg commented Jul 8, 2019

  • Add generateAttributes utility method
  • Add test for jsAttributes
  • Refactoring generateCSSReferences generateJSReferences
  • Update readme to reflect the changes

- Add `generateAttributes` utility method
- Add test for `jsAttributes`
- Refactoring `generateCSSReferences` `generateJSReferences`
- Update readme to reflect the changes
Copy link
Collaborator

@bebraw bebraw left a comment

Choose a reason for hiding this comment

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

Looks like a cool idea to me. Let's see what Artem thinks. 👍

Copy link
Member

@sapegin sapegin left a comment

Choose a reason for hiding this comment

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

This looks like a good idea, yeah!

A few suggestions:

  • Rename jsAttributes and cssAttributes in generateJSReferences and generateCSSReferences to attributes, it's obvious from the function name.
  • Make this props accept object without the need for generateAttributes.

- `generateCSSReferences` and `generateJSReferences` now accept an object
without the need to use `generateAttributes` utility
- Fix `publicPath` option (didn't work)
- Add test for `publicPath`
- Update readme to reflect the changes above
Copy link
Member

@sapegin sapegin left a comment

Choose a reason for hiding this comment

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

Thanks! One minor comment, otherwise looks good to me 🦄

The main question for me now: is this a breaking change, or we can release it as a minor version?

jsAttributes = '',
attributes = {},
}) {
attributes = generateAttributes(attributes);
Copy link
Member

@sapegin sapegin Jul 12, 2019

Choose a reason for hiding this comment

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

Let's not shadow the function argument to make code easier to understand.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @sapegin! In the current release v1.0.0, generateCSSReferences accept two arguments (css, publicPath), in this pull request I changed it to accept an object ({files: css, attributes: cssAttributes, publicPath}). Same situation for generateJSReferences. This is a breaking change for me. Do you think it should be released under v1.1.0 or 2.0.0?

@sapegin
Copy link
Member

sapegin commented Jul 12, 2019

Yeah, let's do 2.0.0 to be safe 🔒

@pldg
Copy link
Contributor Author

pldg commented Jul 12, 2019

I propose another change. If you set output.publicPath in webpack config this should be reflected correctly in mini-html-webpack-plugin instead of manually pass it as option. How do I access webpack output.publicPath within the plugin?

@sapegin sapegin merged commit 28b24f7 into styleguidist:master Jul 19, 2019
sapegin pushed a commit that referenced this pull request Jul 19, 2019
## New features

* Add `attributes` option to `generateJSReferences` and `generateCSSReferences` (resolve [#5](#5)) ([#11](#11) by @pldg)

### Breaking changes

* `generateJSReferences` accepts an object `({files: css, attributes, publicPath}` instead of two arguments `(js, publicPath)`.
* `generateCSSReferences` accepts an object `({files: css, attributes, publicPath}` instead of two arguments `(css, publicPath)`.
@sapegin
Copy link
Member

sapegin commented Jul 19, 2019

🎉 This PR is included in version 2.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants