fix(dev): transform import for commonjs dependencies

[csr632]

...so that user can do named import from them.

This is a different approach from pull/825 to fix #720

In the optimze step, it collect information about optimized deps (whether it is cjs).
When rewriting import during vite serve, if the importee is a "optimized cjs deps", it will get named import from the default export.
For example,

import React, { useState, createContext } from 'react'

will become

import $viteCjsImport1_react from "/@modules/react.js";
const React = $viteCjsImport1_react;
const useState = $viteCjsImport1_react["useState"];
const createContext = $viteCjsImport1_react["createContext"];

It is better than #825 because it doesn't require users to manually specific export names.

[pd4d10]

Does this feature deprecate optimizeDeps.auto config? It seems generate different results if optimizeDeps.auto is false.

[csr632]

Does this feature deprecate optimizeDeps.auto config? It seems generate different results if optimizeDeps.auto is false.

optimizeDeps.auto is used to controll "whether run vite optimize automatically on server start". It is not relavent to this PR. If you have encountered bugs, please provide a reproduction. @pd4d10

[csr632]

@underfin @antfu
Could we merge this?

[csr632]

I have another approach that would be interesting to investigate before merging this PR, if you agree i can open another PR with the approach below:

Instead of rewriting imports we could use a fake entrypoint to pass to rollup that reexports (with ESM exporting syntax) from the commonjs module, this way rollup generate valid ESM esports and not only a default export.

For example in case of react we pass to rollup an entrypoint with the code

export { useState, useEffect, ... } from 'react'
export * from 'react'
import defaultExport from 'react'
export default defaultExport

Rollup processes this file and outputs valid ESM exports

PS. Snowpack does this to allow for named imports from cjs modules
To detect the named exports of the commonjs module we can use https://github.com/guybedford/cjs-module-lexer

This is exactly what my previous PR was doing.
Checkout this comment for why that is deprecated.

[remorses]

Yes you are right, this is definitely a better approach

[underfin]

@csr632 Can you have a try with rollup/plugins#604 instead of cjs-module-lexer

[remorses]

@underfin I would like to migrate the optimizer to esbuild after they add plugins support, can we try not couple the optimizer too much to rollup?

Also, the use of es-module-lexer is better imho, we detect if the user is using named imports, if yes and there are no named imports in the module then they are extracted from the default import

Edit: forget about it, i will just use es-module-lexer in the esbuild version

[antfu]

@knightly-bot build this

[kmacute]

Thanks for this

[Rainmen-xia]

mark

[kmacute]

using rc8

rollback to this pr fixed the issue

waiting for this pr to be merged

[csr632]

We should wait for rollup/plugins#604 to be published before we can merge this PR. So I am turning this PR to draft.

The upstream rollup plugins have been released. Now this PR is ready to be merged! @yyx990803

[csr632]

@underfin @yyx990803 @antfu
This PR is ready to be merged. Let me help if there is anything blocking this PR. Thanks!

[zheeeng]

Any solution for reexporting commonjs module?

// a.ts
export * from 'moduleTranspiledToCommonjs'

// b.ts
import { foo } from './a'

will produce warning:

Uncaught SyntaxError: The requested module '/a.ts' does not provide an export named 'foo'

[SamuelScheit]

I have the same error as @zheeeng. Any updates on this?

[csr632]

It may become too complicated if we support re-exporting cjs. What is the expected behavior of this and how to implement it? 🤔

// a.ts
export * from 'moduleTranspiledToCommonjs1'  // may contain `module.exports.foo = 'value1'`
export * from 'moduleTranspiledToCommonjs2'  // may contain `module.exports.foo = 'value2'`
export * from 'someESModule'  // may contain `export const foo = 'value3'`. It may also contain cjs re-export

// b.ts
import { foo } from './a'
console.log(foo);