Sane buildflow #703

yne · 2024-04-21T12:53:55Z

Description

Based on existing work done by @ILOVEPIE in #693 this PR migrate to a sane build pipeline (which is urgent) while leaving any compatibility-related change to #693 (which is nice, but less urgent).

Rename src/*.js to src/*.mjs and test/*.js to test/*.spec.mjs
Remove unused reify dependency
Use latest Mocha => no more critical vulnerabilities when npm i
Use latest ESLint 9 => need to migrate to they new config format
Deprecate load*/download functions (Why did we depricate the load function? #675) and remove associated tests
Remove dead code (private load*() function, isNode/isBrowser...)
Fix some issues in recent tests addition
Add support for many popular test runner:

npx mocha
npx bun test
npx jasmine "**/*.spec.mjs" # may fail on strict compare

BONUS: This PR also cleanup our ESLint rules:

"ban forEach" is migrate to a "selector" rule
prevent import loop => did nothing
force import file extension => esbuild enforce it already

Tip

This halves (243 => 144) our NPM dependencies

Motivation and Context

Lower our attack surface by half, while keeping the backward-compatibility improvment in #693

How Has This Been Tested?

npm i && npm run test

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

I did npm run test and all tests passed green (including code styling checks).
I have added tests to cover my changes.
My change requires a change to the documentation.
I have updated the README accordingly.
I have read the CONTRIBUTING document.

- Rename src/*.js to src/*.mjs and test/*.js to test/*.spec.mjs - Move misplaced "eslint-plugin-local-rules" to devDependencies - Remove unused reify now that we are fully .mjs - Deprecate load*/download functions and remove associated tests - Remove dead code (private load*() function, isNode/isBrowser...) - Support multiple test runner: ```sh npx mocha npx bun test npx jasmine "**/*.spec.mjs" # may fail on strict compare ```

There are currently 3 local rules: - ban forEach => migrate to a "selector" rule - prevent import loop => did nothing - force import extension => esbuild enforce it already This halves (226 => 139) our NPM dependencies

Use new configuration format since package.json based configuration have been droped

Connum

See my comments - other than that, this looks good! Nice work getting rid of all those depedencies and moving towrds a more modern code base.

src/glyphset.mjs

src/tables/cpal.mjs

src/tables/glyf.mjs

src/font.mjs

Connum · 2024-04-21T18:03:05Z

test/bidi.spec.mjs


        let thaiFont;
        let bidiThai;

-        before(()=> {
+        beforeEach(()=> {
            thaiFont = loadSync('./test/fonts/NotoSansThai-Medium-Testing-v1.ttf');


Why do we need to load/parse the font before each test? If it's not being modified and therefore interfering with following tests, this just adds overhead and increases testing runtime.

it allows to use the same codebase on the 3 most popular test runner
yet it has no significant impact on the overall test execution time

https://mochajs.org/#hooks use .before()/.after() 😢
https://bun.sh/docs/test/lifecycle use .beforeAll()/.afterAll()
https://jasmine.github.io/api/edge/global use .beforeAll()/.afterAll()

I could also switch from mocha to bun test (and save even more NPM dependencies)

npx mocha npx bun test npx jasmine "**/*.spec.mjs"

Or just create a wrapper in test/testutil.mjs with before = before||beforeAll

test/glyph.spec.mjs

src/util.mjs

test/util.js

yne · 2024-04-21T20:11:11Z

Nice work getting rid of all those depedencies and moving towrds a more modern code base.

Props to @ILOVEPIE who did the initial migration. I just reused it PR but stopped before doing legacy-compatibility stuff so he could rebase it PR on it

ILOVEPIE · 2024-04-22T05:02:29Z

So, the point of this is to split my pr into two?

ILOVEPIE

I can't approve of this in it's current state.

eslint-local-rules.js

package.json

src/opentype.mjs

test/opentype.spec.mjs

ILOVEPIE · 2024-04-22T05:50:43Z

test/opentype.spec.mjs

@@ -84,23 +57,6 @@ describe('opentype.js', function() {
        assert.equal(aGlyph.path.commands.length, 14);
    });

-    it('[deprecated] .load() handles a parseBuffer error', function(done) {


I thought we agreed that this would still function in 2.0.0 with a warning, and be removed in a subsequent release.

the 2.0.0 is a major release
major release does break things
so if we are brewing the 2.0.0 it make more sense to put the warning now to ease this major transition

ILOVEPIE · 2024-04-22T05:51:09Z

test/opentype.spec.mjs

@@ -119,7 +75,7 @@ describe('opentype.js', function() {
    });
 });

-describe('opentype.js on low memory mode', function() {
+describe('opentype.mjs on low memory mode', function() {


Error here, this should still read opentype.js

Connum · 2024-04-22T06:24:04Z

As my brain needed a break from trying to implement CFF2 writing for variable glyphs, I'm currently working on a slim (=really just a couple of lines) plugin API to offer support for standalone CFF1 and PS1/Adobe Type 1 files without bloating the main library.

I think I would be on board with removing the load and download functions directly in 2.0.0 without prior depreciation notice if we were to offer a "browserhelper" and "nodehelper" plugin at the same time, references in a console message when trying to call the functions. The browserhelper could also provide the functionality for adding a preview of the font via CSS @font-face as discussed in #62.

That way, all that users had to do would be to add or import another small file delivered together with our lib in order to keep the functionality.

What do you guys think?

yne · 2024-04-22T07:15:54Z

What do you guys think?

for the load/download function, a simple line in the "usage" chapter of the readme would suffice as it is just demonstration of how user can integrate opentype.js in they environment.

but I agree for a separation of concern

This is what jasmine is doing (jasmine/jasmine-core)

yne · 2024-04-22T19:06:19Z

So, the point of this is to split my pr into two?

Yes

this PR remove reify so we can bump Mocha
Your PR integrate SWC to add a .legacy.js build

@Connum @ILOVEPIE : I closed dups comment to keep a readable thread

ILOVEPIE · 2024-05-09T20:09:00Z

Hey, @yne can we get this rebased on the current head so that it can be reviewed and merged if it's ok?

yne · 2024-05-09T21:25:04Z

Hey, @yne can we get this rebased on the current head so that it can be reviewed and merged if it's ok?

sure, I'll ping you once I get back home (~ end of week)

yne requested review from ILOVEPIE and Connum April 21, 2024 13:02

yne added 2 commits April 21, 2024 15:02

Rework eslint rules

48ea8a8

There are currently 3 local rules: - ban forEach => migrate to a "selector" rule - prevent import loop => did nothing - force import extension => esbuild enforce it already This halves (226 => 139) our NPM dependencies

yne force-pushed the sane-buildflow branch from 169ca7e to 48ea8a8 Compare April 21, 2024 13:02

Use eslint@9

e26c62c

Use new configuration format since package.json based configuration have been droped

yne force-pushed the sane-buildflow branch from 8ccc0dc to e26c62c Compare April 21, 2024 14:04

Connum requested changes Apr 21, 2024

View reviewed changes

ILOVEPIE requested changes Apr 22, 2024

View reviewed changes

Apply remarks

38abe35

yne force-pushed the sane-buildflow branch from 2baa5e6 to 38abe35 Compare April 22, 2024 19:15

ILOVEPIE self-requested a review April 24, 2024 19:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sane buildflow #703

Sane buildflow #703

yne commented Apr 21, 2024 •

edited

Connum left a comment

Connum Apr 21, 2024

yne Apr 21, 2024

yne commented Apr 21, 2024

ILOVEPIE commented Apr 22, 2024

ILOVEPIE left a comment

ILOVEPIE Apr 22, 2024

yne Apr 22, 2024

ILOVEPIE Apr 22, 2024

Connum commented Apr 22, 2024 •

edited

yne commented Apr 22, 2024

yne commented Apr 22, 2024 •

edited

ILOVEPIE commented May 9, 2024 •

edited

yne commented May 9, 2024

Sane buildflow #703

Are you sure you want to change the base?

Sane buildflow #703

Conversation

yne commented Apr 21, 2024 • edited

Description

Motivation and Context

How Has This Been Tested?

Types of changes

Checklist:

Connum left a comment

Choose a reason for hiding this comment

Connum Apr 21, 2024

Choose a reason for hiding this comment

yne Apr 21, 2024

Choose a reason for hiding this comment

yne commented Apr 21, 2024

ILOVEPIE commented Apr 22, 2024

ILOVEPIE left a comment

Choose a reason for hiding this comment

ILOVEPIE Apr 22, 2024

Choose a reason for hiding this comment

yne Apr 22, 2024

Choose a reason for hiding this comment

ILOVEPIE Apr 22, 2024

Choose a reason for hiding this comment

Connum commented Apr 22, 2024 • edited

yne commented Apr 22, 2024

yne commented Apr 22, 2024 • edited

ILOVEPIE commented May 9, 2024 • edited

yne commented May 9, 2024

yne commented Apr 21, 2024 •

edited

Connum commented Apr 22, 2024 •

edited

yne commented Apr 22, 2024 •

edited

ILOVEPIE commented May 9, 2024 •

edited