Build process

[tomelliot]

@dariodjuric this is great - thanks for putting it together. What would the build/maintenance process look like for when an update is needed? Would that be a separate repo that builds this repo and pushes the update to npm?

[dariodjuric]

@dariodjuric this is great - thanks for putting it together. What would the build/maintenance process look like for when an update is needed? Would that be a separate repo that builds this repo and pushes the update to npm?

We can set it up as part of this repo - I'm thinking it would be a good idea to automate publishing to npm in a way so that whenever a GitHub release is created, it is published to npm automatically. This should be achievable via a GitHub workflow.

[tomelliot]

Ah perfect 🙌

[dariodjuric]

@tomelliot, could you please create a new access token of type "Automation"? This one can be used to bypass the 2FA - otherwise a new OTP code is required on every release, which is not convenient.

[tomelliot]

@dariodjuric I just created one. I can also add you as a member of the organisation on npmjs.com if that's helpful

[dariodjuric]

@dariodjuric I just created one. I can also add you as a member of the organisation on npmjs.com if that's helpful

That's okay, this is only a one-time thing.

I just tested it and it works!

Here's what you need to do to make a release:

1. Create a new release on GH.
2. Use something like "1.0.3" for the tag and the release name. The release version should be numeric and higher than the version in package.json.
3. Publish the release. This will automatically update package.json with the new version and publish to npm.

Here is the result: https://www.npmjs.com/package/webflow-icons

[dariodjuric]

You can delete the above package from npm, that was just a test one. We can delete the test releases too.

Before making the releases official, we should perhaps update the readme file with more information. Would you like to add some context to it? I can add the howtos and update the contributing guide.

[tomelliot]

Ah great - this is excellent, thanks Dario. I will push some changes to the readme in the next day or two as well.

[tomelliot]

@dariodjuric I'm revisiting this package now - one thing I'm missing is how we can rebuild the package when the underlying SVGs update.

Heroicons have some build scripts in their package.json. What do you think is the best way to do this here - have a separate project or branch that runs the build process, or include it in main?

[dariodjuric]

@dariodjuric I'm revisiting this package now - one thing I'm missing is how we can rebuild the package when the underlying SVGs update.

Heroicons have some build scripts in their package.json. What do you think is the best way to do this here - have a separate project or branch that runs the build process, or include it in main?

Rebuilding the package is essentially making a new release, as every release is unchangeable. This can be done either manually (by rebuilding the icons and then creating a release) or automatically by having a GitHub workflow running on a schedule that rebuilds the package and then makes a new release if any changes are detected.

What do you think?

[tomelliot]

I think manual is fine - the question for me is where to store the .svg files that are used to generate the package, along with the scripts that do the transformation from .svg to components.

I'd like to include as part of the README.md a table showing each of the icons 0 so for that reason it makes sense to me to have the source svgs in the same repo (so that the README.md can display them). That also seems to be the way heroicons does it: https://github.com/tailwindlabs/heroicons/tree/master/src/24/outline

[dariodjuric]

Yes, I would recommend storing them in the repo if they will be shown in the readme. Another option is to pull them from Tailwind's repo, but then this repo would be closely dependent on the Tailwind one, and things might break when changes are done on the Tailwind repo.

We could have one script that pulls the SVGs into this repo (they would need to be committed afterwards), and then an additional set of scripts to do the transformation. These scripts would need to be run in a specific order before making the release.

[tomelliot]

Ah the icons are not coming from the tailwind library - they're coming from Webflow, I just used the tailwind library as inspiration for creating a package.

OK great, I will add the svgs to this package. Do you think it makes sense to copy the tailwind implementation for generating components from the SVGs and include that in webflow-icons?

[dariodjuric]

OK great, I will add the svgs to this package. Do you think it makes sense to copy the tailwind implementation for generating components from the SVGs and include that in webflow-icons?

Yeah, that is perfectly fine. Maybe we should only give credit to Heroicons in the readme (e.g. saying something like "icons are generated similarly as in Heroicons").