modules/index.js should re-export tslib.es6.js instead of tslib.js #143

schickling · 2021-01-14T19:05:56Z

Unless I'm misunderstanding something, I'd expect modules/index.js to re-export ../tslib.es6.js instead of ../tslib.js.

https://github.com/microsoft/tslib/blob/master/modules/index.js#L1

I'm basing my statement on the understanding that exports['.']['import'] should point to some "modern" code:

https://github.com/microsoft/tslib/blob/master/package.json#L29-L34

(The reason I'm opening this issue is that I'm facing some problem in combination with Vite which is based on ESM.)

The text was updated successfully, but these errors were encountered:

yyx990803 · 2021-01-20T02:23:03Z

@DanielRosenwasser would love an eye on this.

From Vite resolver's perspective, module is a non-standard condition in exports, so it resolves to the import condition... which points to an ESM file that imports a UMD file (!!!). This does work in Node.js because Node allows ESM to import commonjs files... however for a native-ESM dev server like Vite, it assumes entries specified by the import condition to only contain valid ESM all the way through.

On the other hand, why doesn't the import condition simply point to tslib.es6.js? What is the point of having the modules/index.js indirection?

This can be fixed on Vite's front by also checking the module condition in exports field, but that is technically non-standard :/

wiesson · 2021-09-07T12:15:22Z

Any updates to this?

I'm currently trying to understand whats wrong, but I have this error in my sveltekit project:

 > .svelte-kit/output/server/app.js:26097:14: warning: Using direct eval with a bundler is not recommended and may cause problems (more info: https://esbuild.github.io/link/direct-eval)
    26097 │     var mod = eval("quire".replace(/^/, "re"))(moduleName);
          ╵               ~~~~

 > .svelte-kit/output/server/app.js:41:7: error: No matching export in "node_modules/tslib/modules/index.js" for import "default"
    41 │ import require$$0$4, { __extends, __assign, __values, __read, __awaiter, __generator, __spreadArray, __rest } from "tslib";
       ╵        ~~~~~~~~~~~~

> Build failed with 1 error:
.svelte-kit/output/server/app.js:41:7: error: No matching export in "node_modules/tslib/modules/index.js" for import "default"
Error: Build failed with 1 error:

milky2028 · 2021-09-28T00:37:45Z

@wiesson Have you been able to figure this out yet? I'm getting the same error. Haven't been able to find anything that fixes it, include aliasing in svelte.config.js to tslib/tslib.es6.js.

wiesson · 2021-09-28T06:52:17Z

@wiesson Have you been able to figure this out yet? I'm getting the same error. Haven't been able to find anything that fixes it, include aliasing in svelte.config.js to tslib/tslib.es6.js.

Unfortunately not :/ I'm also not sure, if its tslib itself or another extension. Somehow deleting .svelte-kit, node_modules and the lock file "solved" my problem without understanding why. But it sometimes occurs every now and then.

samuba · 2021-10-02T15:29:28Z

Have the same problem with sveltekit build in adapter-vercel phase.
I was able to narrow it done to one import that is causing this: import { serverTimestamp } from "firebase/firestore"; (Firestore 9)
@wiesson's delete procedure did not help.

I hack-fixed this by running this script before executing npm run build:

import fs from 'fs'
try {
    const filePath = "node_modules/@firebase/firestore/package.json"
    fs.writeFileSync(filePath, fs.readFileSync(filePath, 'utf8').replace(
        `"node": "./dist/index.node.cjs.js",`, 
        `"node": "./dist/index.esm2017.js",`
    ))
    console.log("fixed vercel adapter")
} catch (err) {
    console.error("error: fixing vercel adapter", err)
}

benterova · 2021-10-05T05:34:12Z

Have the same problem with sveltekit build phase adapter-vercel. I was able to narrow it done to one import that is causing this: import { serverTimestamp } from "firebase/firestore"; (Firestore 9) @wiesson's delete procedure did not help.

I hack-fixed this by running this script before executing npm run build:
import fs from 'fs'
try {
    const filePath = "node_modules/@firebase/firestore/package.json"
    fs.writeFileSync(filePath, fs.readFileSync(filePath, 'utf8').replace(
        `"node": "./dist/index.node.cjs.js",`, 
        `"node": "./dist/index.esm2017.js",`
    ))
    console.log("fixed vercel adapter")
} catch (err) {
    console.error("error: fixing vercel adapter", err)
}

This worked for me as well, although would love to see this fixed for real.

wiesson · 2021-10-05T18:59:56Z

I think this issue is related, isn't it? -> firebase/firebase-js-sdk#5499

@evil-su, could you share your findings so that the firebase team could fix it? :)

wiesson · 2021-10-05T20:36:07Z

https://github.com/firebase/firebase-js-sdk/pull/5532/files

This looks promising 🎉

orta · 2021-10-14T07:32:35Z

Switching to use tslib.es6.js fails to run in the esm-node-native test case in the repo, happy to have a vite test case in here (we already have snowpack for example) but any changes should need to be backwards compatible .

milky2028 · 2021-10-17T15:42:28Z

I had to do this for firestore/lite as well in order to get it to work.

import { readFile, writeFile } from 'fs/promises';

const importJson = async (path) => JSON.parse(await readFile(new URL(path, import.meta.url)));

const path = 'node_modules/@firebase/firestore/package.json';
const pkg = await importJson(path);
pkg.exports['.'].node = './dist/index.esm2017.js';
pkg.exports['./lite'].node = './dist/lite/index.browser.esm2017.js';

await writeFile(new URL(path, import.meta.url), JSON.stringify(pkg));

console.log('Successfully fixed imports.');

antongolub · 2021-11-03T17:55:11Z

@orta,

Can we at least just change re-export to import * as tslib from '../tslib.js'; or smth like that?
This fixes missed default export in esm mode (NODE_OPTIONS=--experimental-vm-modules)

SyntaxError: The requested module '../tslib.js' does not provide an export named 'default'

jogibear9988 · 2021-11-20T16:39:02Z

same issue here: #161

noahbald · 2021-11-21T01:36:42Z

Have the same problem with sveltekit build in adapter-vercel phase. I was able to narrow it done to one import that is causing this: import { serverTimestamp } from "firebase/firestore"; (Firestore 9) @wiesson's delete procedure did not help.

I hack-fixed this by running this script before executing npm run build:
import fs from 'fs'
try {
    const filePath = "node_modules/@firebase/firestore/package.json"
    fs.writeFileSync(filePath, fs.readFileSync(filePath, 'utf8').replace(
        `"node": "./dist/index.node.cjs.js",`, 
        `"node": "./dist/index.esm2017.js",`
    ))
    console.log("fixed vercel adapter")
} catch (err) {
    console.error("error: fixing vercel adapter", err)
}

I've been getting the same issue with other packages when using sveltekit/vite - I've adapted your idea to fix it at the source by adding a default export to tslib.

This seems to fix things for me.

import fs from 'fs'
import path from 'path'

try {
  const filePath = path.resolve('./node_modules/tslib/modules/index.js')
  console.log('fixing tslib export', filePath)
  let file = fs.readFileSync(filePath, 'utf8')
  if (!file.includes('export default')) {
    file += '\nexport default tslib;\n'
  }
  fs.writeFileSync(filePath, file)
} catch (err) {
  console.error('error: fixing tslib export', err)
}

It's not ideal so I'd love to see this fixed on tslib's end or from sveltekit/vite (not too sure which one is causing the issue at hand)

rbuckton · 2022-02-08T18:35:31Z

NodeJS does not consider tslib.es6.js to be an ES Module because it has a .js extension. tslib.es6.js predates NodeJS's ESM support and wasn't really designed for it. NodeJS does treat modules/index.js as an ES Module due to the package.json in that folder containing { "type": "module" }.

Rather than have modules/index.js contain a third copy of the helpers that we need to maintain, we chose to have it re-export an existing set of helpers. We can't re-export tslib.es6.js, since that would still be treated as a CommonJS module by Node and would error on the use of the export keyword. Instead we chose to re-export tslib.js, which is a valid CommonJS module.

The only alternative I can think of is to move the contents of tslib.es6.js into modules/index.js, and change tslib.es6.js to just export * from "./modules/index.js";. That keeps the duplication to a minimum as its still only two copies to maintain.

rbuckton · 2022-02-10T20:11:06Z

Is this still an issue in Vite? I added a test locally using vite and it seems to import tslib just fine as is.

rbuckton · 2022-02-10T20:29:36Z

I've added a test for vite@2.8.0 in #172 and I'm not seeing the error that's being described in this issue. @schickling (or anyone else experiencing this), can you review the PR and let me know if I'm missing something in that test that would help me reproduce the issue you are describing?

thescientist13 · 2022-02-10T20:44:17Z

If it helps, the use case that led me here was trying to work with Material Web Components, in my case was just testing out @material/mwc-button and using ESM from the browser via import map.

The dependency chain is pretty short:

@material/mwc-button has a direct dependency on tslib
To resolve tslib for ESM, you hit the issue here, either resolving exports or module in package.json (in my case I am following the export map)

rbuckton · 2022-02-11T18:38:03Z

If it helps, the use case that led me here was trying to work with Material Web Components, in my case was just testing out @material/mwc-button and using ESM from the browser via import map.

Would import maps give you the ability to remap tslib as well?

thescientist13 · 2022-02-11T20:34:04Z

Would import maps give you the ability to remap tslib as well?

Yes, if hand rolling the import map as the 1st party, this would be doable.

But similar to the Vite use case, the files to resolve (and the import map) are being determined programmatically, and so is entirely based on what the dependencies themselves define via their package.json. So this fix would be very useful to all ecosystem tools looking to operate against the spec in NodeJS.

rbuckton · 2022-02-18T21:00:59Z

If it helps, the use case that led me here was trying to work with Material Web Components, in my case was just testing out @material/mwc-button and using ESM from the browser via import map.

The dependency chain is pretty short:

@material/mwc-button has a direct dependency on tslib

To resolve tslib for ESM, you hit the issue here, either resolving exports or module in package.json (in my case I am following the export map)

Can you provide a more detailed repro?

thescientist13 · 2022-02-20T17:48:15Z

Yeah, you can see this branch where I am trying to integrate MWC and hitting this issue. Following the ESM spec would be great here, so thanks in advance for taking a look. 🙏

JavascriptMick · 2023-12-11T13:46:40Z

I had a related issue. In my case, my site is deployed on Netlify and I have a transient dependency on tslib from "@azure/ai-form-recognizer": "^5.0.0",.

After trying a bunch of different things that didn't work, I found this worked.

Added an explicit import for tslib
"tslib": "^2.6.2",
added a fix (hack) script in my repo
build_scripts/fix_tslib_node.mjs

import fs from 'fs'
try {
  const filePath = "node_modules/tslib/package.json"
  fs.writeFileSync(filePath, fs.readFileSync(filePath, 'utf8').replace(
    `"node": "./modules/index.js",`,
    `"node": "./tslib.es6.mjs",`
  ))
  console.log("node setting for tslib fixed (hacked)")
} catch (err) {
  console.error("error: fixing node setting for tslib", err)
}

changed Build and Deployment -> Continuous Deployment -> Build Settings -> Build command
node build_scripts/fix_tslib_node.mjs && npm run build

thescientist13 mentioned this issue Oct 15, 2021

[WIP] example with Material Web Components ProjectEvergreen/greenwood-getting-started#42

Draft

antongolub mentioned this issue Nov 3, 2021

fix: fix re-export at esm entry point #158

Closed

rbuckton linked a pull request Feb 8, 2022 that will close this issue

Move helpers from tslib.es6.js to modules/index.js #171

Open

rbuckton mentioned this issue Feb 10, 2022

Add a test for vite #172

Merged

andrewbranch mentioned this issue May 1, 2023

Add Node-specific export condition for ESM entrypoint that re-exports CJS #201

Merged

lluiscab mentioned this issue Jul 12, 2023

Metro unstable_enablePackageExports cause app crash getsentry/sentry-react-native#3152

Closed

JavascriptMick mentioned this issue Dec 11, 2023

@azure/ai-form-recognizer breaks Nuxt3 on netlify (Cannot find package 'tslib') Azure/azure-sdk-for-js#28028

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

modules/index.js should re-export tslib.es6.js instead of tslib.js #143

modules/index.js should re-export tslib.es6.js instead of tslib.js #143

schickling commented Jan 14, 2021 •

edited

yyx990803 commented Jan 20, 2021 •

edited

wiesson commented Sep 7, 2021

milky2028 commented Sep 28, 2021

wiesson commented Sep 28, 2021 •

edited

samuba commented Oct 2, 2021 •

edited

benterova commented Oct 5, 2021

wiesson commented Oct 5, 2021 •

edited

wiesson commented Oct 5, 2021

orta commented Oct 14, 2021

milky2028 commented Oct 17, 2021

antongolub commented Nov 3, 2021 •

edited

jogibear9988 commented Nov 20, 2021

noahbald commented Nov 21, 2021 •

edited

rbuckton commented Feb 8, 2022 •

edited

rbuckton commented Feb 10, 2022

rbuckton commented Feb 10, 2022

thescientist13 commented Feb 10, 2022

rbuckton commented Feb 11, 2022

thescientist13 commented Feb 11, 2022 •

edited

rbuckton commented Feb 18, 2022

thescientist13 commented Feb 20, 2022

JavascriptMick commented Dec 11, 2023 •

edited

modules/index.js should re-export tslib.es6.js instead of tslib.js #143

modules/index.js should re-export tslib.es6.js instead of tslib.js #143

Comments

schickling commented Jan 14, 2021 • edited

yyx990803 commented Jan 20, 2021 • edited

wiesson commented Sep 7, 2021

milky2028 commented Sep 28, 2021

wiesson commented Sep 28, 2021 • edited

samuba commented Oct 2, 2021 • edited

benterova commented Oct 5, 2021

wiesson commented Oct 5, 2021 • edited

wiesson commented Oct 5, 2021

orta commented Oct 14, 2021

milky2028 commented Oct 17, 2021

antongolub commented Nov 3, 2021 • edited

jogibear9988 commented Nov 20, 2021

noahbald commented Nov 21, 2021 • edited

rbuckton commented Feb 8, 2022 • edited

rbuckton commented Feb 10, 2022

rbuckton commented Feb 10, 2022

thescientist13 commented Feb 10, 2022

rbuckton commented Feb 11, 2022

thescientist13 commented Feb 11, 2022 • edited

rbuckton commented Feb 18, 2022

thescientist13 commented Feb 20, 2022

JavascriptMick commented Dec 11, 2023 • edited

schickling commented Jan 14, 2021 •

edited

yyx990803 commented Jan 20, 2021 •

edited

wiesson commented Sep 28, 2021 •

edited

samuba commented Oct 2, 2021 •

edited

wiesson commented Oct 5, 2021 •

edited

antongolub commented Nov 3, 2021 •

edited

noahbald commented Nov 21, 2021 •

edited

rbuckton commented Feb 8, 2022 •

edited

thescientist13 commented Feb 11, 2022 •

edited

JavascriptMick commented Dec 11, 2023 •

edited