Skip to content
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

TS(): Testing fabric 6 package configuration and code splitting. Fix fabric object access #8622

Merged
merged 19 commits into from Feb 2, 2023

Conversation

asturur
Copy link
Member

@asturur asturur commented Jan 24, 2023

Motivation

Try to package the library with modern standards
Some notes i took from here about main/module/browser
https://esbuild.github.io/api/#main-fields

IN theory from a react or bundled project we do:

import * as fabric from 'fabric'

or

import { Canvas, Textbox } from 'fabric'

Without any of those beeing tree-shakable for now.

And from browsers or cdn imports we refer to

'fabric/dist/fabricjs.umd.min.js'

And also i still have no idea if the main es build is supposed to be minified or not.

Changes

  • main fabric export is now the UMD, while the module directive is an ES build named fabric.js.
  • removed access to the global fabric. constant in a mixin that was a leftover of the ENV migration
  • added copy-paste temporary data to getEnv(), not a great place but for now it works as a generic container
  • added an extra build script ( unused for now ) to experiment with single file transpiling and bundling

Gist

In Action

@github-actions
Copy link
Contributor

github-actions bot commented Jan 24, 2023

Build Stats

file / KB (diff) bundled minified
fabric 903.135 (+0.309) 304.947 (0)

name: 'fabric',
format: 'es',
sourcemap: true,
},
Copy link
Member Author

Choose a reason for hiding this comment

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

this change makes it work with the 3 setup i tested so far, but is all rollup based, i want to check webpack too and and the standard next.js and SWC setup.

I m not saying i think we should have 2 builds ( or 3 ) but right now i m collecting data on how to ship something that works out of the box and is not tied to a gigantic fabric monolith.

@github-actions
Copy link
Contributor

github-actions bot commented Jan 24, 2023

Coverage after merging v6-package-testing into master will be

83.06%

Coverage Report
FileStmtsBranchesFuncsLinesUncovered Lines
fabric.ts100%100%100%100%
src
   Collection.ts95.65%95%89.66%97.83%205–206, 231–232
   CommonMethods.ts100%100%100%100%
   Intersection.ts100%100%100%100%
   Observable.ts87.23%85.29%84.62%89.36%138–139, 164–165, 39–40, 48, 57, 91, 99
   Pattern.ts95.77%94.29%100%96.43%124, 135, 144
   Point.ts100%100%100%100%
   Shadow.ts98.48%96%100%100%156
   cache.ts97.06%90%100%100%56
   config.ts75%64.29%66.67%82.76%138, 138, 138, 138, 138–140, 151–153
   constants.ts100%100%100%100%
   env.ts73.33%53.33%100%80%29, 29–30, 30, 30, 32, 32, 34, 36, 38–39, 69
   typedefs.ts100%100%100%100%
src/brushes
   BaseBrush.ts100%100%100%100%
   CircleBrush.ts0%0%0%0%100, 102–104, 113, 113, 113, 115, 117, 119–121, 123–126, 133–134, 141, 143, 28–29, 37–41, 45–49, 56–59, 67–71, 73, 81, 81, 81, 81, 81–82, 84, 84, 84–87, 89, 97–98
   PatternBrush.ts97.06%87.50%100%100%21
   PencilBrush.ts91.01%82.35%100%93.75%122–123, 152, 152–154, 176, 176, 276, 280, 285–286, 68–69, 84–85
   SprayBrush.ts0%0%0%0%100–101, 103–104, 112, 112, 112, 112, 112–113, 115–116, 123–124, 126, 128–132, 141, 145–146, 146, 154, 154, 154–157, 159–162, 166–167, 169, 171–174, 177, 184–185, 187, 189–190, 192, 199–200, 202–203, 206, 206, 213, 213, 217, 22–23, 25–27, 27, 27–29, 33, 42, 49, 56, 63, 70, 89–91, 99
src/canvas
   Canvas.ts79%77.01%83.33%79.77%1010–1011, 1011, 1011–1013, 1015–1016, 1016, 1016, 1018, 1026, 1026, 1026–1028, 1028, 1028, 1034–1035, 1043–1044, 1044, 1044–1045, 1050, 1052, 1083–1085, 1088–1089, 1093–1094, 1211–1213, 1216–1217, 1290, 1410, 1504–1505, 1511, 1515–1516, 1532, 1554, 1601, 1606, 1654, 172, 197, 306–307, 310–314, 319, 342–343, 348–353, 373, 373, 373–374, 374, 374–375, 383, 388–389, 389, 389, 39, 390, 392, 401, 407–408, 408, 408, 43, 451, 459, 463, 463, 463–464, 466, 548–549, 549, 549–550, 556, 556, 556–558, 578, 580, 580, 580–581, 581, 581, 584, 584, 584–585, 588, 597–598, 600–601, 603, 603–604, 606–607, 619–620, 620, 620–621, 623–627, 633, 640, 680, 680, 680, 682, 684–688, 694, 700, 700, 700–701, 703, 706, 711, 724, 751, 751, 809–810, 810, 810–811, 813, 816–817, 817, 817–818, 820–821, 824, 824–826, 829–830, 900, 912, 919, 940, 972, 993–994
   SelectableCanvas.ts93.82%90.71%94.12%96.11%1137, 1137–1138, 1141, 1161, 1161, 1220, 1270–1271, 1292, 1300, 1413–1414, 1416–1417, 1437–1438, 556–557, 562, 572, 705–706, 708–709, 709, 709, 755–756, 817–818, 871–873, 903, 908–909, 938–939
   StaticCanvas.ts94.93%90.15%97.96%97.25%1086–1087, 1087, 1087–1088, 1208, 1218, 1272–1273, 1276, 1311–1312, 1389, 1398, 1398, 1402, 1402, 1449–1450, 1667, 1667–1668, 1717, 1720, 1723, 1723, 1723, 1726, 1729, 1729, 1729, 285–286, 303, 383–384, 386–387, 846
   TextEditingManager.ts100%100%100%100%
src/color
   Color.ts92.16%86.49%100%94.29%330–331, 335–336, 339–340, 58, 88–89, 89, 91, 91, 91–92, 94–95
   color_map.ts100%100%100%100%
   constants.ts100%100%100%100%
   util.ts100%100%100%100%
src/controls
   Control.ts93.90%88.89%90.91%97.73%235, 319, 319, 354
   changeWidth.ts100%100%100%100%
   controls.render.ts81.63%78%100%84.78%106, 111, 121, 121, 45, 50, 61, 61, 65–72, 81–82
   default_controls.ts86.67%66.67%100%100%122, 129
   drag.ts100%100%100%100%
   polyControl.ts6.15%0%0%11.11%100, 105, 119, 119, 119, 121–124, 124, 127, 134, 17, 25–28, 30, 30, 30, 30, 30, 30, 30, 30, 50–56, 56, 56, 56, 56, 58, 63–64, 66, 76, 82–83, 83, 83–84, 88–90, 90, 90, 90, 90, 92
   rotate.ts19.57%12.50%50%21.43%41, 45, 51, 51, 51–52, 55–57, 59, 59, 59, 59, 59–61, 61, 61–63, 65, 65, 65–67, 67, 67–68, 73, 73, 73–74, 76, 78, 80–81
   scale.ts93.49%92.77%100%93.67%129–130, 132–134, 148–149, 181–183, 42
   scaleSkew.ts78.79%64.29%100%85.71%27, 29, 29, 29, 31, 33, 35
   skew.ts91.03%79.31%100%97.67%130–131, 162–163, 170, 176, 178
   util.ts100%100%100%100%
   wrapWithFireEvent.ts100%100%100%100%
   wrapWithFixedAnchor.ts100%100%100%100%
src/filters
   BaseFilter.ts19.89%20%30%17.82%100–102, 102, 102–103, 110–113, 113, 113–114, 120, 120, 120–123,

@ShaMan123 ShaMan123 mentioned this pull request Jan 26, 2023
48 tasks
@asturur
Copy link
Member Author

asturur commented Jan 27, 2023

I made some experiments do not take the diffs as definitives yet, looking at options

chrome >= 58
chrome >= 64
safari >= 11
firefox >= 58
Copy link
Member Author

Choose a reason for hiding this comment

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

those for examples are browsers released Jan 2018.
But to be honest i would like to decide by canvas features.
Like which is the minimum set of browsers with advanced text metrics?
For the beta is not relevant we can readjust

}
]
]
}
Copy link
Member Author

Choose a reason for hiding this comment

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

this would be an alternative config file, very loose, that would behave as tsc, just stripping types.
This could be useful for developers that want to import files directly and then want to bundle and transpile on their own.

@asturur
Copy link
Member Author

asturur commented Jan 28, 2023

Ok this seems a decent approach, apart i need to fix that we can't add random things to the fabric object, because now it is an export and you can't add things to it, is read only.

@asturur
Copy link
Member Author

asturur commented Jan 30, 2023

Ok after a bit of pain i m here:
image

This works, isn't exactly what we want now but is a path forward.
The import code looks like this:

import { useEffect } from 'react'
import { Canvas } from 'fabric/dist/src/canvas/Canvas';
import { Textbox } from 'fabric/dist/src/shapes/Textbox';
import './App.css'

function App() {

  useEffect(() => {
    const c = document.getElementById('c');
    if (c!.hasAttribute('data-fabric')) {
      return;
    }
    const fabricCanvas = new Canvas('c');
    const text = new Textbox('Hello 6.0', {});
    fabricCanvas.add(text);
  }, []);

  return (
    <div className="App">
      <canvas id="c" width="1280" height="720" ></canvas>
    </div>
  )
}

export default App

And the import logic works, while the app doesn't because we are full of side effects yet.
side effects will break tree shaking both for the single imports and for dead code removal from the main bundle.

We have 2 builds, one for ES and one from UMD, type works and then we can also transpile the SRC folder as it is for single file imports, but that shouldn't be considered a feature yet, but more something to experiment with.

Is still strange that in order to import Text and Canvas i have to pull in both Rect and Group but eventually we still have some import to tweak here and there.

@asturur asturur changed the title Testing fabric 6 package configuration TS() Testing fabric 6 package configuration and code splitting. Fix fabric object access Jan 30, 2023
@asturur asturur changed the title TS() Testing fabric 6 package configuration and code splitting. Fix fabric object access TS(): Testing fabric 6 package configuration and code splitting. Fix fabric object access Jan 30, 2023
@asturur
Copy link
Member Author

asturur commented Jan 30, 2023

Also at some point we shoud check esbuild seems like it does what rollup does but in a tenth of the time.


// TODO: consider using https://github.com/swiing/rollup-plugin-import-assertions so we can import json in node and have rollup build pass
export { version as VERSION } from '../package.json';
export const VERSION = version;
Copy link
Member Author

@asturur asturur Jan 30, 2023

Choose a reason for hiding this comment

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

a note about import assertion.
Looks like that the whole JSON has to be imported as a default import, or at least this is what was happening while i added the babel plugin to support import assertion.

Copy link
Contributor

Choose a reason for hiding this comment

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

weird that the syntax must be like this. but babel...

Copy link
Member Author

Choose a reason for hiding this comment

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

is just the plugin i found that is not great.
If i use the good one, to support assertion, i get all the package.json in the codebase.
While this is a plugin that swaps the statement with a const, but has been poorly written

Copy link
Contributor

@ShaMan123 ShaMan123 left a comment

Choose a reason for hiding this comment

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

First of all, good job! This part is the hardest and most frustrating IMO.
I don't have too much to say accept that it is disappointing that there is so much trial and error in this field, I would expect rollup to explain all this in a few boilerplates. But here we are.

I don't understand, if I want to use fabric in a tree shakable manner I can't use the rollup outputs? Sounds ridiculous, why would anyone use rollup then? I can't believe it is true.

My main point to change in this PR are the index files, hopefully that will fix this issue.
We must not use const, only import/export. That is why we should have more index files for utils, filters etc.
I am quite sure this is what is holding back tree shaking.
I also think it must be possible doing:

import {Canvas, Textbox} from 'fabric'

And have tree shaking work w/o importing files directly. That is the point of tree shaking, elsewise you are manually reducing the tree by manual imports. So that can't be considered as tree shaking. No need to support that IMO once tree shaking works.
I am also against exporting a default monolith, I thought you are against as well. Is this just a step forward? If a dev wants to use the fabric namespace they should do:

import * as fabric from 'fabric'

What is your opinion?

type TFabricEnv = {
document: Document;
window: Window;
isTouchSupported: boolean;
isLikelyNode: boolean;
nodeCanvas: Canvas;
jsdomImplForWrapper: any;
copyPasteData: TCopyPasteData;
Copy link
Contributor

Choose a reason for hiding this comment

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

this should die in a PR I need to port

Copy link
Member Author

Choose a reason for hiding this comment

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

if different copy paste code make this unnecessary, great.

Copy link
Contributor

Choose a reason for hiding this comment

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

yes, using the native event transferData is the path forward

@@ -1640,7 +1640,8 @@ export class FabricObject<
cloneAsImage(options: any): Image {
const canvasEl = this.toCanvasElement(options);
// TODO: how to import Image w/o an import cycle?
return new Image(canvasEl);
const ImageClass = classRegistry.getClass('image');
Copy link
Contributor

Choose a reason for hiding this comment

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

nice!


// TODO: consider using https://github.com/swiing/rollup-plugin-import-assertions so we can import json in node and have rollup build pass
export { version as VERSION } from '../package.json';
export const VERSION = version;
Copy link
Contributor

Choose a reason for hiding this comment

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

weird that the syntax must be like this. but babel...

@asturur
Copy link
Member Author

asturur commented Jan 30, 2023

First of all, good job! This part is the hardest and most frustrating IMO. I don't have too much to say accept that it is disappointing that there is so much trial and error in this field, I would expect rollup to explain all this in a few boilerplates. But here we are.

I don't understand, if I want to use fabric in a tree shakable manner I can't use the rollup outputs? Sounds ridiculous, why would anyone use rollup then? I can't believe it is true.

My main point to change in this PR are the index files, hopefully that will fix this issue. We must not use const, only import/export. That is why we should have more index files for utils, filters etc. I am quite sure this is what is holding back tree shaking. I also think it must be possible doing:

import {Canvas, Textbox} from 'fabric'

And have tree shaking work w/o importing files directly. That is the point of tree shaking, elsewise you are manually reducing the tree by manual imports. So that can't be considered as tree shaking. No need to support that IMO once tree shaking works. I am also against exporting a default monolith, I thought you are against as well. Is this just a step forward? If a dev wants to use the fabric namespace they should do:

import * as fabric from 'fabric'

What is your opinion?

There are 2 way to obtain partial imports.
One is the bundler actually going for the file and understanding what code is used and what not and remove it from the bundle or from the single JS files you import ( bundles or not ).
That could work both from fabric or from the single files, but actually can't because of:

  • prototype changes
  • assigning controls how we do it
  • class Registry
    When you want to use this way, you mark the dependency as side effect free and you let the bundler run human written code that will remove the extra code. FabricJS is not side effect free yet.

The other way is to provide disjointed files and you import what you need, and each file follow its own dependency graph. On top of that the approach above can be still be applied.

I do agree that we should not create consts in the export, that breaks tree shaking, and that can be fixed, but since all the rest is not ready now, i wouldn't bother.

The official method of import stays import { a, b } from 'fabric' for now and the one with the mixed files is just a way to have a ready way to experiment with it but we should consider it not supported, i wouldn't document it either.

The index filex are necessary but i don't want them to be used in the code files because then we have to guards for us using the * as filters and then using it as an object. So i would totally use them to build the package but i would avoid to refer them in the middle of the code if possible for preferences

It could also be that some weird export sytnax works too export { a, b } as filters but never tried

@ShaMan123
Copy link
Contributor

Tackling these:

  • prototype changes - a quick look shows we can eliminate the few usages by extracting logic to a util (_setLineDash and a few things in Group that I did just because importing was impossible at the time)
  • assigning controls - we can do that in the constructor, it makes sense
this.controls = objectDefaultControls
  • class Registry - I don't understand what is blocking here...

Regarding the index files, ok.
I still lack the understanding of what is missing. I am trying to run the code with examples that worked. Some don't agree to with master and with this branch. I will try more.

@ShaMan123
Copy link
Contributor

ShaMan123 commented Jan 30, 2023

Running next project now fails
Before I managed to get it working with a dynamic import w/o SSR.
I don't understand what is happening now but it tries to evaluate fabric before I import it...

@asturur
Copy link
Member Author

asturur commented Jan 30, 2023

Let's add the fabricjs-webpack changes in place for the basice react setup, and you can push there a folder with the next example? so we can test it.

@ShaMan123
Copy link
Contributor

ShaMan123 commented Jan 30, 2023

possible, it is the next app from #8135
https://github.com/fabricjs/fabric.js/tree/sandbox-ci/.codesandbox/templates/next

Must use the cli or link fabric manually
If you want I can push it there

@asturur
Copy link
Member Author

asturur commented Jan 30, 2023

Tackling these:

  • prototype changes - a quick look shows we can eliminate the few usages by extracting logic to a util (_setLineDash and a few things in Group that I did just because importing was impossible at the time)
  • assigning controls - we can do that in the constructor, it makes sense
this.controls = objectDefaultControls
  • class Registry - I don't understand what is blocking here...

Regarding the index files, ok. I still lack the understanding of what is missing. I am trying to run the code with examples that worked. Some don't agree to with master and with this branch. I will try more.

The class registry gets run when you import a file for that class.
That means that it force you to keep all the code that is in the Canvas file for example outside the. class itself, if the bundler goes for unused code removal will also remove teh call to the registry because it has no idea what are you doing with that, if it belong to the Canvas call or to the below or above class.

Prototype changes have the same issue, but those are fixed when we do that in the constructor.

Assigning controls in the constructor is a no go because then you don't have anymore a control set but hundreds of them.
But can all be solved with a setup function probably that you import and launch in your project or simply you write your own if you want something different.

Fixing the default values as first will clear some lines of code that are outside classes and will let us see better what is left.

@ShaMan123
Copy link
Contributor

The class registry gets run when you import a file for that class.
That means that it force you to keep all the code that is in the Canvas file for example outside the. class itself, if the bundler goes for unused code removal will also remove teh call to the registry because it has no idea what are you doing with that, if it belong to the Canvas call or to the below or above class.

Didn't understand. Sorry.
Unused classes shouldn't get registered, that is what we want, right? Do you think the opposite is happening? That since the class is registered it gets bundled no matter what and won't be shaken off?

Assigning controls in the constructor is a no go because then you don't have anymore a control set but hundreds of them

If you assign the same defaultObjectControls object it is still a single shared object as you wish it to be.
True, it will require a loop to assign a different control set to objects. But no more.
We have been in this discussion so I won't poke your eye. Sorry if I did.

@ShaMan123
Copy link
Contributor

ShaMan123 commented Jan 30, 2023

Fixing the default values as first will clear some lines of code that are outside classes and will let us see better what is left.

Ahh so you think this is holding back tree shaking because of the assignment to the prototype?

@ShaMan123
Copy link
Contributor

We could use a devops/CI person... lending a hand

@asturur
Copy link
Member Author

asturur commented Jan 30, 2023

so the issue with unused code is that if this is our file

Class Canvas {

}

classRegistry.setClass('canvas', Canvas);

and then in the application

import { Canvas } from '../canvas/Class';

The unused code removal will won't know what to do with the line classRegistry.setClass('canvas', Canvas);.
It will skip it and break fabric behaviour.
It either skips all the function calls not imported breaking the app, or import them all not saving any code.
It can't pick up smartly.

@asturur
Copy link
Member Author

asturur commented Jan 30, 2023

Sorry i m not being super clear with explanations.
Everything that is inside a file, called as a function instead of being an export, is possibly concern with tree shaking.

commit 90e42df
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:59:19 2023 +0200

    fix(): object caching value workaround for SSR

commit 1278696
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:58:54 2023 +0200

    ssr test

commit 6761606
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:57:38 2023 +0200

    restore jsdom cleanup in static canvas

    due to FabricObject to canvas method

commit 8ad5647
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:56:41 2023 +0200

    Update object.js

commit d29352e
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:47:36 2023 +0200

    SSR changes

commit c98d6e0
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:19:49 2023 +0200

    prepare for SSR

commit bb66394
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:05:27 2023 +0200

    Update package.json

commit 4a3d4aa
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 12:04:21 2023 +0200

    Update rollup.config.mjs

commit 74299c3
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 12:01:03 2023 +0200

    cleanup

commit 78bf675
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 11:52:34 2023 +0200

    cleanup

commit c18651c
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 11:47:43 2023 +0200

    node stream methods

commit b7e03ca
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 11:27:39 2023 +0200

    Update rollup.config.mjs

commit 46eb9fd
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 11:26:05 2023 +0200

    working!

commit a1534c4
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 10:26:49 2023 +0200

    node build
@ShaMan123
Copy link
Contributor

@asturur take a look at 7d22d71
It is squashed so you an revert it.
Should fix most issues with SSR along with improved rollup config.
Thoughts?

@ShaMan123
Copy link
Contributor

ShaMan123 commented Jan 31, 2023

I accidently committed dist files. Sorry.
Changes made:
getEnv can't be called when importing fabric because then SSR isn't possible with decent importing.

@ShaMan123
Copy link
Contributor

ShaMan123 commented Jan 31, 2023

try the following on branch v6-sandbox (uses #8632 ) and on branch v6-sandbox-test1 (uses this branch) and v6-sandbox-test2 which is the same as v6-sandbox-test1 besides that the fabric import is done in the correct timing and it has the browser field in package.json v6-sandbox-test1...v6-sandbox-test2

npm run sandbox start -- -t next
npm run sandbox start -- -t node

v6-sandbox: all works (doesn't need the browser field in package.json) accept next api that should work on server side and use fabric in node context
v6-sandbox-test1: fails to load fabric in browser context in next app because of the browser field in package.json that was removed
v6-sandbox-test2: all works (restored the browser field in package.json) with special handling of imports so fabric is imported at the right timing.

@ShaMan123
Copy link
Contributor

I am very excited to share that SSR works out of the box with #8632 tested in v6-sandbox

@ShaMan123 ShaMan123 mentioned this pull request Jan 31, 2023
@ShaMan123
Copy link
Contributor

@ShaMan123
Copy link
Contributor

ShaMan123 commented Feb 1, 2023

I have made progress with tree shaking and found the following:

  • registering classes can't be done as we do if we want tree shaking (I think that is what you meant in a previous comment)
  • we need to solve how static class properties are build with babel or something since in the build these props are assigned to the class with a _defineProperty call that too blocks tree shaking (which is absolutely strange since the ecosystem uses classes and tree shaking and static props)

Take a look at 8006244, it is a test for tree shaking. Tree shaking works for brushes for example. You can see that I didn't import brushes and the entire brushes code was removed.

@asturur
Copy link
Member Author

asturur commented Feb 2, 2023

https://github.com/fabricjs/fabricjs-webpack/tree/master/next-app

added the broken next-app here.
I see that the breakage is the bundler trying to do stuff with node deps.
So since we know that needs to be solved, we can merge this first part and continue with the node entrypoint

@asturur asturur merged commit 8a8904e into master Feb 2, 2023
ShaMan123 added a commit that referenced this pull request Feb 2, 2023
commit 0631c6a
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Thu Feb 2 14:16:01 2023 +0200

    rename files: `dist/fabric*` => `dist/index*`

commit 7438d30
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Thu Feb 2 14:15:56 2023 +0200

    Update tsconfig.json

commit a496545
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Thu Feb 2 13:53:51 2023 +0200

    Update tsconfig.json

commit 8937a56
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Thu Feb 2 13:14:45 2023 +0200

    rename node index file

commit f3d5320
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Thu Feb 2 13:04:22 2023 +0200

    canvas streaming methods

commit 5fcd4b0
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Thu Feb 2 12:35:35 2023 +0200

    better exports field

commit b9c81a6
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Thu Feb 2 10:50:08 2023 +0200

    enhance env tests

commit e4fab60
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Thu Feb 2 10:26:32 2023 +0200

    Revert code splitting

    This reverts commit 8c04490.

    Revert "Update treeShakingOutput.mjs"

    This reverts commit 7054438.

    Revert "rename to index"

    This reverts commit 8829519.

    Revert "move index files"

    This reverts commit 08ba23d.

    Revert "Update util.ts"

    This reverts commit ed04657.

    Revert "organize controls index"

    This reverts commit 91b0c06.

    Revert "organize"

    This reverts commit da802c9.

    Revert "tree shaking test"

    This reverts commit 8006244.

commit c2f8b5b
Merge: 7054438 8a8904e
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Thu Feb 2 10:20:06 2023 +0200

    Merge branch 'master' into node-build

commit 8a8904e
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Thu Feb 2 02:13:14 2023 +0100

    TS(): Testing fabric 6 package configuration and code splitting. Fix fabric object access (#8622)

commit 7054438
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 14:51:34 2023 +0200

    Update treeShakingOutput.mjs

commit 8829519
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 14:40:22 2023 +0200

    rename to index

    this is revertable by design

commit 08ba23d
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 14:39:20 2023 +0200

    move index files

commit ed04657
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 14:37:28 2023 +0200

    Update util.ts

commit 91b0c06
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 14:35:10 2023 +0200

    organize controls index

commit da802c9
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 14:33:35 2023 +0200

    organize

commit 8c04490
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 14:29:22 2023 +0200

    index files

commit 8006244
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 14:25:14 2023 +0200

    tree shaking test

commit 200dcf8
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 00:19:30 2023 +0200

    Update build.yml

commit d2af7c7
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 00:10:28 2023 +0200

    Update env.js

commit 624b624
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Wed Feb 1 00:02:19 2023 +0200

    rm

commit b697b4b
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 23:51:29 2023 +0200

    restore dist

commit a6caef7
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 23:16:03 2023 +0200

    main entry for node

commit 1a97d33
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 17:36:28 2023 +0200

    node env cjs/mjs

commit 95049f3
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 15:22:51 2023 +0200

    rename

commit d1ee15c
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 15:18:56 2023 +0200

    Update types.ts

commit e754bc6
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 14:35:34 2023 +0200

    fix exports field

commit 90e42df
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:59:19 2023 +0200

    fix(): object caching value workaround for SSR

commit 1278696
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:58:54 2023 +0200

    ssr test

commit 6761606
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:57:38 2023 +0200

    restore jsdom cleanup in static canvas

    due to FabricObject to canvas method

commit 8ad5647
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:56:41 2023 +0200

    Update object.js

commit d29352e
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:47:36 2023 +0200

    SSR changes

commit c98d6e0
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:19:49 2023 +0200

    prepare for SSR

commit bb66394
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 13:05:27 2023 +0200

    Update package.json

commit 4a3d4aa
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 12:04:21 2023 +0200

    Update rollup.config.mjs

commit 74299c3
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 12:01:03 2023 +0200

    cleanup

commit 78bf675
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 11:52:34 2023 +0200

    cleanup

commit c18651c
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 11:47:43 2023 +0200

    node stream methods

commit b7e03ca
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 11:27:39 2023 +0200

    Update rollup.config.mjs

commit 46eb9fd
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 11:26:05 2023 +0200

    working!

commit a1534c4
Author: ShaMan123 <shacharnen@gmail.com>
Date:   Tue Jan 31 10:26:49 2023 +0200

    node build

commit ce1874b
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Mon Jan 30 11:59:36 2023 +0100

    fix tests to do not reference fabric

commit 1f8583c
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Mon Jan 30 11:41:04 2023 +0100

    try different

commit edc36d0
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Mon Jan 30 11:35:11 2023 +0100

    pretty and changelog

commit 8a0638a
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Mon Jan 30 11:32:53 2023 +0100

    fixed fabric access

commit ddbf31e
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Mon Jan 30 11:29:44 2023 +0100

    fixed fabric access

commit f3ab5d0
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Mon Jan 30 11:10:51 2023 +0100

    no unused deps

commit 3b459fc
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Mon Jan 30 11:05:03 2023 +0100

    progress;

commit 887b288
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Sun Jan 29 17:50:15 2023 +0100

    declaration are back

commit 40af839
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Sun Jan 29 17:16:26 2023 +0100

    where are my types

commit 536b644
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Sat Jan 28 21:46:52 2023 +0100

    different import

commit 6c43775
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Sat Jan 28 19:40:10 2023 +0100

    build is ok, types are not

commit 8033843
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Sat Jan 28 19:40:01 2023 +0100

    build is ok, types are not

commit 248066b
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Fri Jan 27 01:06:26 2023 +0100

    missin file

commit 3fb6cd4
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Fri Jan 27 01:04:50 2023 +0100

    remove build

commit a59eb23
Merge: 3e9dad0 84b7a35
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Fri Jan 27 01:04:23 2023 +0100

    Merge branch 'master' into v6-package-testing

commit 3e9dad0
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Fri Jan 27 01:02:38 2023 +0100

    save so far

commit 9c01ab1
Author: Andrea Bogazzi <andreabogazzi79@gmail.com>
Date:   Tue Jan 24 13:32:57 2023 +0100

    module config
@ShaMan123 ShaMan123 deleted the v6-package-testing branch February 5, 2023 05:15
@ShaMan123 ShaMan123 restored the v6-package-testing branch February 5, 2023 05:15
@ShaMan123 ShaMan123 deleted the v6-package-testing branch February 5, 2023 05:15
ShaMan123 pushed a commit that referenced this pull request Mar 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants