feat(vite): add tsconfig paths resolution plugin

[barbados-clemens]

Current Behavior

vite-tsconfig-paths plugin isn't able to work with tmp tsconfigs to make incremental building work

Expected Behavior

nx supports incremental building with vite

Related Issue(s)

TODO:

• validation across different vite setups with/without buildable libs
• write e2e tests
• handle TODOs
• cleanup register work within executor to just generate tsconfigs

Fixes #

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nx-dev	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 17, 2023 3:22pm

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit ce7876d. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 1 target

• nx affected -t e2e-macos --parallel=1 --base=187842e14c2d8b65d6c2b265502e2b08519acb7c --head=ce7876d052067c85630c75bf17ccc65b39bf330d

---

Sent with 💌 from NxCloud.

[barbados-clemens]

This solves the issues I came across where a default @nx/js library will be built with the following package.json

{
  "name": "@acme/js-lib",
  "version": "0.0.1",
  "type": "module",
  "peerDependencies": {
    "tslib": "2.6.0"
  },
  "main": "./src/index.js",
  "types": "./src/index.d.ts"
}

and vite will be unable to load it as RollUp claims it cannot find the named exports, or the tsconfig-paths will not be able to resolve the exports object since it doesn't exist.

The same issue happens in the original plugin being used as well vite-tsconfig-paths.

This fallbacks to the root level tsconfig where the .ts files will be loaded instead so projects that don't include export objects or commonjs will still be able to be used in the project with buildLibsFromSource=false just will be forced to be build from source.

This can be fixed in the userland by changing the tsconfig settings to use NodeNext and type:module in package.json which allows vite to see the named exports

i.e. the output switches from

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const tslib_1 = require("tslib");
tslib_1.__exportStar(require("./lib/lib-js"), exports);
//# sourceMappingURL=index.js.map

to just

export * from './lib/lib-js';

[barbados-clemens]

@jaysoo would like your opinion on this, to see if this makes sense or if we should see what we can do to get cjs built libs working inside vite.

[barbados-clemens]

As far as I can tell, since these paths never being used by vite downstream, there isn't a reason to register them anymore.

[mandarini]

Interesting, and thank you @barbados-clemens !! I'm going to test this out today. I am thinking, should we really drop the use of vite-tsconfig-paths plugin, and rely only on the tsconfig-paths? I'm thinking that maybe vite-tsconfig-paths covers some specific use cases for vite, and using vite-tsconfig-paths in the nx-vite-paths plugin (instead of tsconfig-paths) could potentially save us some maintenance? Again, have not tried out the PR yet, will do today, and not sure what more vite-tsconfig-paths does, so I'm just speculating!

In any case, I'll test it out today! :D thanks!

I also want to see @jaysoo opinion!

[mandarini]

Cool! So, yes, I tested on this repo: https://github.com/mandarini/vite-paths/tree/test-caleb on the branch test-caleb, which I added lots of interdependencies, and some to cover Storybook path resolution as well. All works great! So it's a ✅ from me, but with the question whether we really want to drop vite-tsconfig-paths completely, and not rely on it at all!

[mandarini]

Approving to move this forward, but still would like one look from @jaysoo

[github-actions]

This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request.