-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeScript 2.7 + esModuleInterop #2200
Conversation
fix datetime example importsPreview: documentation | landing | table |
@@ -4,7 +4,7 @@ | |||
* Licensed under the terms of the LICENSE file distributed with this project. | |||
*/ | |||
|
|||
import * as classNames from "classnames"; | |||
import classNames from "classnames"; | |||
import * as React from "react"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't we need to do the same for all import *
statements? I believe namespace imports are now discouraged altogether, so we should make that change across the board in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only needed for things that are effectively “module.exports = something” and don’t have flags marking them as originally es modules.
TS has been doing synthetic wrong. Now you’re doing it right! (Namespaces are not invocable)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems the only offenders were classnames
, moment
, moment-timezone
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool, so we're still blocking this PR on fixing import * as moment
right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typescript@2.4.1: | ||
version "2.4.1" | ||
resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.4.1.tgz#c3ccb16ddaa0b2314de031e7e6fee89e5ba346bc" | ||
typescript@2.7.1: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you use yarn why
to find out why we have this constraint? I don't want to be pinned to 2.7.1 anywhere, it has bugs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh this is from typedoc for sure https://github.com/TypeStrong/typedoc/releases/tag/v0.10.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
womp. I filed TypeStrong/typedoc#720
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 they're slightly different requests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok... given the response on my issue, I think we'll have to live with this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah for now. on my issue he said he'd have something next week for 2.7.2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey guys, I've released a patch update to TypeDoc which updates Typescript to 2.7.2
does this work with consumers using older TS versions? do they also have to enable the |
@ericanderson IIRC you're using rollup on some projects? Mind taking a look at this PR? |
@@ -4,7 +4,7 @@ | |||
* Licensed under the terms of the LICENSE file distributed with this project. | |||
*/ | |||
|
|||
import * as classNames from "classnames"; | |||
import classNames from "classnames"; | |||
import * as React from "react"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only needed for things that are effectively “module.exports = something” and don’t have flags marking them as originally es modules.
TS has been doing synthetic wrong. Now you’re doing it right! (Namespaces are not invocable)
The JavaScript generated from doing this is usable by webpack, rollup, and node. What’s funny is for rollup we actually had to write plugins to convert es code from “import * as X from “Y”” to drop the star as. The es modules you were publishing before were actually wrong and are now correct |
yes, that's the linked issue #2144 we're trying to fix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, you're right, I missed the moment stuff. lgtm, just fix the tslib dependency range
@@ -33,7 +33,7 @@ | |||
"@blueprintjs/core": "^2.0.0-rc.2", | |||
"classnames": "^2.2", | |||
"react-day-picker": "^7.0.7", | |||
"tslib": "^1.5.0" | |||
"tslib": "^1.9.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think all of these need to be ~1.9.0
, similar to the typescript version range
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think so, it's really a minimum for the new functions added to support esModuleInterop
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I thought that the behavior of these functions can change across minor versions... but that doesn't seem to be the case looking at its README. We do it for internal libraries, but this should be fine; we should probably switch over to a ^
range
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
switch what over to ^
range?
makes sense to leave typescript with ~
to allow patches but exclude minors (cuz those can change things significantly)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, I meant switch our internal libraries which use "tslib": "~
over to ^
. unrelated to this PR.
I'll take this over and finish it up, hoping to publish a 2.0.0-rc.3 with this |
semantic merge conflcitPreview: documentation | landing | table |
Fixes #2144
Changes proposed in this pull request:
esModuleInterop
andallowSyntheticDefaultImports