Add setup to pretest script

[yihao03]

What is the purpose of this pull request?

• Documentation update
• Bug fix
• Feature addition or enhancement
• Code maintenance
• DevOps
• Improve developer experience
• Others, please explain:

Overview of changes:
Whenever there are changes to dependencies or other files, some of the artifacts from tsc build or test script will
be stale and need to be regenerated. Therefore, sometimes it may past tests locally but fail in CI due to stale state
or fail tests locally after pulling changes from remote. This PR adds a pre-test cleanup step to delete those artifacts
and make sure that tests are run in a clean state.

Anything you'd like to highlight/discuss:

Testing instructions:
run npm run test and check the logs that npm run setup is correctly ran and verify that tests pass as expected.

Proposed commit message: (wrap lines at 72 characters)
Add pre-test setup step to clean stale artifacts

---

Checklist: ☑️

• Updated the documentation for feature additions and enhancements
• Added tests for bug fixes or features
• Linked all related issues
• No unrelated changes

---

Reviewer checklist:

Indicate the SEMVER impact of the PR:

• Major (when you make incompatible API changes)
• Minor (when you add functionality in a backward compatible manner)
• Patch (when you make backward compatible bug fixes)

At the end of the review, please label the PR with the appropriate label: r.Major, r.Minor, r.Patch.

Breaking change release note preparation (if applicable):

• To be included in the release note for any feature that is made obsolete/breaking

Give a brief explanation note about:

• what was the old feature that was made obsolete
• any replacement feature (if any), and
• how the author should modify his website to migrate from the old feature to the replacement feature (if possible).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.20%. Comparing base (1856ad8) to head (0bcb802).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2824      +/-   ##
==========================================
+ Coverage   72.18%   72.20%   +0.01%     
==========================================
  Files         134      134              
  Lines        7449     7454       +5     
  Branches     1647     1555      -92     
==========================================
+ Hits         5377     5382       +5     
+ Misses       2026     1944      -82     
- Partials       46      128      +82     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Incogdino]

LGTM the pretest script works as expected

[gerteck]

I'm thinking about the performance implications of adding adding a setup in the pretest

• The setup script is defined specifically to do a fresh install ("setup": "npm ci && npm run clean && lerna run prepare"), where the command npm ci (clean install) performs a clean install, meaning it deletes your node_modules folder and reinstalls all dependencies from scratch.

-> Our CI currently runs

markbind/.github/workflows/ci.yml

Lines 37 to 38 in 77a3dc0

	- run: npm run setup
	- run: npm run test

npm run setup runs twice. The second time (inside test), it will delete all the modules installed by the first step and download/install them all over again. This doubles the installation time.

One option is to remove the run step in CI. I do understand the issue where maybe ts files are not rebuilt so tests fail causing confusion. However, the CI (clean install) seems to be a bit of a performance hit.

Wdyt?

[yihao03]

Could removing the run: npm run setup in the CI script cause any trouble? Otherwise I think it is fine to remove it.

On a sidenote, I experimented using bun and Vite (instead of npm and webpack) for MarkBind. I left my agent on it to do the migration and it seemed like quite a bit of work to migrate our toolchain over. The main work comes from making the repo typescript and ESM native, and converting jest to the bun built-in test suite. However, the performance improvements seem very promising

[gerteck]

Could removing the run: npm run setup in the CI script cause any trouble? Otherwise I think it is fine to remove it.

I think we could do that if we do merge in the pretest. Btw, what about the scenario where I only want to run vue package tests and run npm run test from the vue package root? Similarly for cli or core.

On a sidenote, I experimented using bun and Vite (instead of npm and webpack) for MarkBind. I left my agent on it to do the migration and it seemed like quite a bit of work to migrate our toolchain over. The main work comes from making the repo typescript and ESM native, and converting jest to the bun built-in test suite. However, the performance improvements seem very promising

That sounds good, it definitely is worth exploring and feasible implementing once maintenance work is done, looking forward to see what's possible!

[yihao03]

I think moving to bun would probably come after the TypeScript migration is complete. From my preliminary (and not very scientific) testings, it seems to deliver a 3x improvement in speed when running tests and significantly faster install sleeps.

[yihao03]

Btw, what about the scenario where I only want to run vue package tests and run npm run test from the vue package root? Similarly for cli or core

are you suggesting to move the pretest script to the individual packages?

[gerteck]

Btw, what about the scenario where I only want to run vue package tests and run npm run test from the vue package root? Similarly for cli or core

are you suggesting to move the pretest script to the individual packages?

Don't really have any suggestions, was just wondering 😆 I suppose it would be hard to add the pretest script into individual packages, maybe we don't have to do that hmm

[yihao03]

Just so that we are on the same page, is the concern we wont be running the pretest if we ran package specific test-scripts? I guess that would be alright because the error will be caught by the pre-push hook.