refactor: Reworked build system #25
Conversation
|
Works like a charm! ❤️ |
|
Ready to merge and deploy on your command) |
|
Should be ready to merge. I don't think it'll need a deploy though, as nothing is functionally different. I did realize that I neglected to copy over the Edit: Thought flags could just be overridden. Had to add an extra command to accommodate the |
| # packages | ||
| /hex | ||
| /hsl | ||
| /hslString | ||
| /hsv | ||
| /rgb | ||
| /rgbString | ||
| /HexInput |
There was a problem hiding this comment.
Discussion:
I feel that this PR is going to make the top-level repo structure more complex.
And that'll make the barrier to entry way higher.
I just thought that keeping so many folders in repo root isn't the best idea.
It seems to me that we could combine build-packages.js solution and the one you did. I mean to create the same package.json, dist subfolders, run the same command etc automatically using one JS-script. I'm going to create a separate PR to try.
There was a problem hiding this comment.
Fair enough. Though I still think this will just move the complexity into your tooling instead. It'll also be slower, though depending on what you're used to, might not be important.
You'll just need to first generate a valid package.json, then run the Microbundle in that directory, rather than the other way around.
|
Going to close this PR. These ideas and concepts helped us to improve building process in #26. |
|
#26 is the successor |
I looked into doing this as I was having issues wrangling Microbundle into outputting types in #23. The issue is outlined a bit there.
This would not only be a solution to that problem but also has the potential to be an improvement outside of that. Reduces surface area of maintenance and locally I'm seeing builds take half the time.