Trying to import the package in a Typescript file:
import * as SendGrid from '@sendgrid/mail';
gives the following error on tsc build:
src/libs/communications.ts(1,27): error TS2497: Module '"<long path>/node_modules/@sendgrid/mail/index"' resolves to a non-module entity and cannot be imported using this construct.
Any known resolution for this issue except using the following workaround?
import SendGrid = require('@sendgrid/mail'); // tslint:disable-line
@SPARTAN563,
Any ideas on this one? Thanks!
Hi @thinkingserious,
It looks like this SO post addresses this issue:
https://stackoverflow.com/questions/39415661/what-does-resolves-to-a-non-module-entity-and-cannot-be-imported-using-this
From what I understand...
In packages/mail/src/mail.d.ts (https://github.com/sendgrid/sendgrid-nodejs/blob/master/packages/mail/src/mail.d.ts), it looks like the export is using CommonJS export, and not ES6 export default:
//packages/mail/src/mail.d.ts line 33
export = new MailService()
Thus, you can't use ES6 imports as the OP desired:
import * as SendGrid from '@sendgrid/mail';
Instead, he needed to use CommonJS require. It's not a 'hack'. It's just following the same convention:
import SendGrid = require('@sendgrid/mail');
Thanks @duncanleung!
@ShaharHD,
Does that answer solve your issue?
Not really ... as my original post actually gave the workaround which was
import SendGrid = require('@sendgrid/mail'); // tslint:disable-line
I was asking to see if there's a cleaner way of doing it as in TS the standard is to have tslint to not allow require (hence the // tslint:disable-line)
Maybe this should be included in the README.md of the repo as the workaround for using sendgrid with TypeScript?
@thinkingserious Referencing the same SO article:
"If you control both modules, you can use export default instead"
https://stackoverflow.com/questions/39415661/what-does-resolves-to-a-non-module-entity-and-cannot-be-imported-using-this
The long-term fix and action item here, is to rewrite any CommonJS export = to use the ES6 export default in the sendgrid-nodejs lib
If you agree / approve that this is the correct solution, I'd like to take a stab at the fix.
Please advise. Thanks!
Thanks @ShaharHD,
For now, could you please add the workaround to our TROUBLESHOOTING section for hacktoberfest?
@adamreisnz, thoughts on @duncanleung's solution?
@thinkingserious ES6 export/import syntax isn't supported yet in Node 8 last I checked, so we can't switch from requires to imports etc.
https://medium.com/the-node-js-collection/an-update-on-es6-modules-in-node-js-42c958b890c
And:
Modules should be natively available in the Node.js version 10, in about april 2018.
https://tech.io/playgrounds/5262/native-es-modules-in-node-js
@adamreisnz Oh, right =p Thanks for the feedback and links on ES6 export/import syntax in Node.
Seems in TS 2.6.x a breaking change that requires the export of the library to be fixed
it seems the only workaround now is to lock down TS version to 2.5.x?
@ShaharHD thanks for bringing that to our attention, I'll get a PR put together to address it quickly.
Thank you @SPARTAN563!
Why wasn't this included in 6.2.0?
It should be deployed later today, @ShaharHD. Thanks!
Somewhat related, how would I use the index.d.ts from the lib? I've tried a few different variations of the following:
import SendGrid = require('@sendgrid/mail')
export interface Foo {
mail: Sendgrid.MailService
}
This doesn't work, nor do the variants, all resulting in either cannot find name or cannot find namespace
Hello @killtheliterate,
Would you mind creating a new issue? Thanks!
With Best Regards,
Elmer
Most helpful comment
Hi @thinkingserious,
It looks like this SO post addresses this issue:
https://stackoverflow.com/questions/39415661/what-does-resolves-to-a-non-module-entity-and-cannot-be-imported-using-this
From what I understand...
In
packages/mail/src/mail.d.ts(https://github.com/sendgrid/sendgrid-nodejs/blob/master/packages/mail/src/mail.d.ts), it looks like the export is using CommonJS export, and not ES6export default:Thus, you can't use ES6 imports as the OP desired:
Instead, he needed to use CommonJS require. It's not a 'hack'. It's just following the same convention: