I’m porting my app to embroider, and I have an addon that has a TypeScript-based library as a dependency. While this works fine and good without embroider, as soon as I add embroider, the named imports come back undefined (without error).
For example take,
import { ItemA, ItemB, ItemC } from 'my-ts-library';
This works in pre-emborider ember 4.x builds (with ember-auto-import 2.x),
but with embroider, item-a, item-b, and item-c are resolved undefined.
Here is the tsconfig for the typescript library:
{
"compilerOptions": {
"target": "es2017",
"module": "commonjs",
"resolveJsonModule": true,
"declaration": true,
"sourceMap": true,
"outDir": "./dist",
"strict": true,
"noUnusedLocals": true,
"typeRoots": [
"./node_modules/@types",
"./typings"
],
"esModuleInterop": true
}
}
also, all the files are setup in an index.ts file as follows
export { default as ItemA } from './item-a'
export { default as ItemB } from './item-b'
export { default as ItemC } from './item-c'
Is there any additional wepack config I need in my addon or test-suite setup that allows imports to be handled in the same way, or is there a more preferred tsconfig to enable this?
Does your addon have the ember-try embroider scenarios? If so are they passing? it could be that the addon is not embroider compatible yet. also you may need to provide the extension for the import. I’ve noticed in some cases embroider prefers that.
its not an addon, just a commonjs typescript library, so no ember-try. Will try the extension.
Messing with extensions didn’t work for me. I do think there is something in the way that commonjs library is exporting that doesn’t show up for my embroider app. I wonder if there is some special webpack sauce that can help.
Maybe also of note when I import from my library like:
import MyTsLibrary from 'my-ts-library';
I get something like this
so basically just an empty object with only _esModule: true set on it.
Hmm id expect ember-auto-import to resolve it in that case, i wish i could be more help, what does the library look like in node_modules and is the package pointing to the transpiled version?
Thanks for responding and trying to help. The strange thing is my pre-embroider build resolves it with auto-import and runs fine. its transpiled to javascript in node_modules in its dist directory, which I assume where its supposed to be. My company owns the source for the library, so I can play with it. I guess I just need to find out why its different between embroider and current ember-cli with the same auto-import version, and I need to figure out what is preferred with exports/packaging.
Might be work trying DEBUG="ember-auto-import:*" on classic ember then with embroider and comparing the difference. It might log a warning or error. Another thing you could check is the .embroider folder in your node_modules your package could be under the rewritten packages folder, might be worth checking if embroider is trying to do something with it
I’ve noticed when I run embroider builds with the auto-import debug flag it always just gives me one line of debug log
That’s it lol.
since its just a ts library it doesn’t show up in rewritten packages.
ok, I tweaked the Typescript lib to make it work, but it requires using a different module strategy (esnext vs commonjs). Here are the new values:
{
"compilerOptions": {
"target": "es2017",
"module": "ESNEXT",
"lib": ["dom", "esnext"],
"declaration": true,
"sourceMap": true,
"outDir": "./dist",
"strict": true,
"noUnusedLocals": true,
"moduleResolution": "node",
"typeRoots": [
"./node_modules/@types",
"./typings"
],
"allowSyntheticDefaultImports": true,
"esModuleInterop": true
}
}
I’d like to keep the library as-is using commonjs (as there’s other non-ember stuff that’s using it in this way. I guess I could do a seperate commonjs and esm build. I’d like to understand why there’s a problem and if there’s anything I can do on the ember-auto-import/webpack side of things to make it work, so I’ll continue to investigate.
