This is probaly a major effort.
Why
This how other repositories do
the extensions folder we have today is an hack and solves only partially the issue.
the node import for fabricjs solved a bunch of issues but is also an hack and people have opinions on what to install and why ( canvas and jsdom ) and i don't want to deal with that
A package for node and browser would provably solve
How
Ideally we end up with a packages folder where there is a core package that containers fabricjs as it is today, and a small package per extension.
A package for node and browser that just add the env wrapper on top of fabric-core.
This should be doable with yarn or pnpm but it needs to be investigated.
Also is probable that fabricJS package requires a name change in order to support @fabricjs/core and @fabricjs/gradient-controls just to make an example.
This would allow for easier pick up from developers, and every package could have its own small readme file and would be displayed easily in the native github interface. On top of that we don't have to publish everything every time, if you need to add a new package you don't need to update fabricjs for it.
Every package should reference fabricJS as a depedency and not bundle it during build.
Each package outside core would have only a modern build, no umd file for scripts tags in quick examples.
We would drop some convenience for modernity.
Typescript / lint / prettier configs needs to be the same, hopefully referenced from core and just reused.
Each package needs to have its own test command, but should be a single test command that runs them all for the CI.
With time then the github actions files can be instructed to run specific actions only on the packages that actually received changes, exactly as we do for changelog.md
e2e tests needs to be split as well, and when fabricJS is changed, everything needs to be checked, but when an extension is changed only its subset of tests can be run ( probably )
The main website on fabricJS.com then needs to be updated to handle it.
This is a disruptive change but better now than later when there are more extensions.
We also need scripts to create a new package with all the necessary scaffolding
This is probaly a major effort.
Why
This how other repositories do
the extensions folder we have today is an hack and solves only partially the issue.
the node import for fabricjs solved a bunch of issues but is also an hack and people have opinions on what to install and why ( canvas and jsdom ) and i don't want to deal with that
A package for node and browser would provably solve
How
Ideally we end up with a packages folder where there is a core package that containers fabricjs as it is today, and a small package per extension.
A package for node and browser that just add the env wrapper on top of fabric-core.
This should be doable with yarn or pnpm but it needs to be investigated.
Also is probable that fabricJS package requires a name change in order to support @fabricjs/core and @fabricjs/gradient-controls just to make an example.
This would allow for easier pick up from developers, and every package could have its own small readme file and would be displayed easily in the native github interface. On top of that we don't have to publish everything every time, if you need to add a new package you don't need to update fabricjs for it.
Every package should reference fabricJS as a depedency and not bundle it during build.
Each package outside core would have only a modern build, no umd file for scripts tags in quick examples.
We would drop some convenience for modernity.
Typescript / lint / prettier configs needs to be the same, hopefully referenced from core and just reused.
Each package needs to have its own test command, but should be a single test command that runs them all for the CI.
With time then the github actions files can be instructed to run specific actions only on the packages that actually received changes, exactly as we do for changelog.md
e2e tests needs to be split as well, and when fabricJS is changed, everything needs to be checked, but when an extension is changed only its subset of tests can be run ( probably )
The main website on fabricJS.com then needs to be updated to handle it.
This is a disruptive change but better now than later when there are more extensions.
We also need scripts to create a new package with all the necessary scaffolding