-
Notifications
You must be signed in to change notification settings - Fork 223
Stop publishing allinone bundle. Bump major. #230
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
base: master
Are you sure you want to change the base?
Stop publishing allinone bundle. Bump major. #230
Conversation
|
The build step alone is not the reason the bundle is published. Have a look at the package.json, there's a reference there to the dist directory. |
Yes, there is a reference to If I do `npm publish --dry-run` outputSide-topic: maybe we also want to |
|
Thanks for helping me understand! I feel we are tackling the core dependency part of the library. If we bump the major version (which is the right thing to do, breaking the contract), I wonder if we should solve the dependency/packaging part once and for all, and not force our consumers to upgrade again to a version 3 soon. I'm looking at #225 which seems to want to modernise the distribution? |
|
That's a good point. I can avoid bumping to v2 for now. Do we want to create a v2 branch to accumulate these changes before publishing a major? |
|
If possible I would like to avoid creating a branch which will sit here for longer. I'd rather keep the PR open as a reminder of what we are trying to achieve. If on the other hand we merge this into the main branch we would be blocked from releasing whenever we wanted or forced into a release branch for minor version changes we want to push out before. If cleaning up becomes a chain of breaking changes we can still go that route. Sounds OK? |
Related to #229 (comment).
Stop publishing allinone bundle. The bundle is still being generated inside the build folder, which is used for tests. I've intentionally left it to avoid too many changes at once. I can take a look at removing it from the build folder altogether in a follow-up PR (if there's interest).
Bump to v2 since this is a breaking change.
Screen.Recording.2026-01-14.at.17.47.49.mov