-
-
Notifications
You must be signed in to change notification settings - Fork 589
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
[Modification] plugin-typescript - Support new compiler options of TS 4.5+ - nodenext
/ node12
#1058
Comments
I should add that granted I'm aware that full support for |
related: #1020 (comment) i am assigning my self to this issue now as i am aware of the current TypeScript Roadmap and i am using Nightly Typescript anyway for building so it is a no brainer to debug the new modes please add any concerns here i will transport that to the TypeScript Repo if needed so that we save overhead. |
Hey folks. This issue hasn't received any traction for 60 days, so we're going to close this for housekeeping. If this is still an ongoing issue, please do consider contributing a Pull Request to resolve it. Further discussion is always welcome even with the issue closed. If anything actionable is posted in the comments, we'll consider reopening it. ⓘ |
Definitely not stale given TS 4.6 is dropping imminently, so this issue is quite pertinent. |
@typhonrt do not worry i am aware of that even if that is closed |
This is delayed because i am not even sure if typescript introduces a new ModuleKind at present the code base does not reflect that https://github.dev/microsoft/TypeScript look there and do a full text seach for ModuleKind the node-resolve plugin could be improved and should support maybe a more strict algo but here is nothing to do at this point in time this is some what related: |
It does indeed... Both in ModuleKind and ModuleResolutionKind. Pulled from the main repo / not branch: This likely will be a blocker for folks trying to use this functionality w/ Should probably also make sure |
@typhonrt sorry i do not fully get what the problem will be can you please create a minimal example tsconfig and additional files that will produce some wrong result? |
The initial description provided above in the OP is pretty clear what the problem is regarding. As it relates to a real world application, I have a NPM library package that uses sub-module exports. IE the As mentioned in the OP as long as the peer dependency for TS remains lower than 4.6 adding the actual integer values in for Node12 / NodeNext and while at it ES2020 / ES2022 is the likely solution. There is a general peer dependency conflict with the beta 4.6 release of TS (for Svelte preprocess and likely the rollup plugin), so I'm waiting for 4.6 to officially drop in ~5 days to continue testing. Since my project is open source I'll provide a link to the demo repo consuming the package with sub-module exports after 4.6 drops. The changes specified will make it work. |
@typhonrt i looked more deep into it and i guess the same stuff applys for existing big typescript projects they will need to use indipendent tsconfig.json files as references with individual settings so composit projects will solve that. i expirenced that in bigger ts projects a single resolve algo will never fit all module situations while "node" solves the most situations i suggest to create a extra composit project that you call dependencie consumption or something like that and reference the tsconfig.json inside that then you switch there the resolve algo to "node" then in your main dev project you will consume the composit project does that make sense for you? |
@frank-dspeed Sounds like a whole lot more ceremony to be honest and TS doesn't need anymore of that! I'll be forking this plugin and making the changes and submit a PR as the fixes are trivial. Might be a couple of weeks as I'm busy with other dev presently, but this is "on the list". |
do not get me wrong but the main problem i am facing is the translation of concepts Typescript works with diffrent module types (moduleKind) and rollup works with ESM only. While we tend to transpil into ESM before doing rollup. So i am not sure if it makes sense to not treat them all as ESM as for rollup only ESM Exists your use case sounds more like a typescript packaging feature that is also great stuff and WiP. You do not need a fork or anything a simple repo that shows a error with typescript nightly would be more then enough. |
Yeah.. I'll post an update when I can get to this. My use case is that I'm delivering a library / development package that uses sub-module exports that includes It's going to be anywhere from 2-4 weeks for me to take a look likely as a complete TS validation of my package is on the tail end of the official release TODO list. |
Hey folks. This issue hasn't received any traction for 60 days, so we're going to close this for housekeeping. If this is still an ongoing issue, please do consider contributing a Pull Request to resolve it. Further discussion is always welcome even with the issue closed. If anything actionable is posted in the comments, we'll consider reopening it. ⓘ |
Heh; not stale. I've been delayed on taking a look, but the TS 4.7 final release is just around the corner and this finally brings full support for node12 / nodenext. Most likely working on this in May. |
I'm still delaying any TS support for my library projects for a bit longer, but just want to update things on the state of TS 4.7+ as there is no longer a So the proposed fix for the Rollup TS plugin while the peer dependency remains at >= 3.7.0 for TS is to add in specific case statements with the numerical values. This makes the switch statement from normalize.ts:
Also change in preflight.ts:
A note that ES2020 is used which is TS 3.8.x level feature above, but also need to add the I suggest bumping the peer dependency of TS to 3.8.0 as that actually has |
Since 4.7 has been out a bit now, I'm in favor of bumping the dependency to match. |
I am not sure, is this issue being fixed or not? I try to read rollup and this plugin source code for half an hour, but I was too unfamilar with rollup systerm. My problem is that I switched to {
"name": "vuepress-shared",
"type": "module",
"exports": {
".": "./lib/node/index.js",
// this line I make <pkg>/client pointing to <pkg>/lib/client/index.js
"./client": "./lib/client/index.js",
"./lib/client": "./lib/client/index.js",
"./lib/client/*": "./lib/client/*",
"./noopModule": "./lib/client/noopModule.js",
"./package.json": "./package.json"
},
} While importing
So it seems that rollup will actually let ts find I am sure that rollup is actually reading {
options: {
allowSyntheticDefaultImports: true,
allowUnreachableCode: false,
allowUnusedLabels: false,
exactOptionalPropertyTypes: true,
noFallthroughCasesInSwitch: true,
strict: true,
noImplicitOverride: true,
noImplicitReturns: true,
noPropertyAccessFromIndexSignature: true,
noUncheckedIndexedAccess: false,
noUnusedLocals: true,
noUnusedParameters: true,
baseUrl: '/home/mister-hope/projects/vuepress-theme-hope',
module: 99,
moduleResolution: 99,
resolveJsonModule: true,
downlevelIteration: false,
importHelpers: true,
importsNotUsedAsValues: 0,
newLine: 1,
noEmitOnError: true,
removeComments: false,
inlineSources: false,
inlineSourceMap: false,
sourceMap: true,
allowJs: false,
checkJs: false,
esModuleInterop: true,
forceConsistentCasingInFileNames: true,
lib: [ 'lib.dom.d.ts', 'lib.esnext.d.ts' ],
target: 7,
diagnostics: false,
listEmittedFiles: false,
skipLibCheck: true,
pretty: true,
rootDir: '/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src',
configFilePath: '/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/tsconfig.json',
noEmitHelpers: true,
noEmit: false,
emitDeclarationOnly: false,
noResolve: false
},
watchOptions: undefined,
fileNames: [
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/shims-category.d.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/shims-type.d.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/client/index.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/client/composables/index.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/client/composables/useBlogCategory.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/client/composables/useBlogType.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/node/category.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/node/index.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/node/plugin.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/node/type.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/node/utils.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/shared/frontmatter.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/shared/index.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/shared/internal.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/shared/options.ts',
'/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src/shared/types.ts'
],
projectReferences: undefined,
typeAcquisition: { enable: false, include: [], exclude: [] },
raw: {
extends: '../../tsconfig.base.json',
compilerOptions: {
module: 'ESNext',
skipLibCheck: true,
rootDir: './src',
moduleResolution: 'NodeNext'
},
include: [ './src' ],
compileOnSave: false
},
errors: [],
wildcardDirectories: {
"/home/mister-hope/projects/vuepress-theme-hope/packages/blog2/src": 1
},
compileOnSave: false,
autoSetSourceMap: false
} |
@Mister-Hope at last i did not invest into fixing it at present because i am undergoing some general iterations about module systems in bigger groups if you want my 5 cent on this You should not use the new resolve algos stay with node and create composit project folders for the once where you need node next also bundel them indipendent |
This is not the solution though; supporting the most recent module resolution capabilities of TS is necessary to support sub-package exports. I have clearly outlined the code changes above and if the peer dependency is going to stay at TS 3.7 you just have to insert the new / valid module values. If you need a PR with the fix I've outlined above which 100% solves the problem let me know. It'll take 5 minutes to make the PR and submit it. Just takes the will of the maintainers to recognize it as the solution. :) I know we're all busy.. But this is not going away as a current pain point for those using modern TS features.. ;P Can you comment why what I have proposed is not acceptable? |
Looks like there is an independent PR for this issue. #1194 |
|
@rollup/plugin-typescript
latest
Expected Behavior / Situation
Allow new module and module resolution compiler options of
node12
andnodenext
to be activated.Actual Behavior / Situation
Current behavior of compiler option normalization does not take into account new features of
TS 4.5+
Modification Proposal
On lines 48-50 of normalize.ts. If one specifies module as
nodenext
ornode12
it is coerced toesnext
under the default condition. This will not work for the new functionality exposed in Typescript4.5+
.Given the peer dependency for @rollup/plugin-typescript being so low the only thing I can think of is adding in case statements with the actual value for
ts.ModuleKind.NodeNext
andts.ModuleKind.Node12
for themodule
compiler option.nodenext
is 199node12
is 100Edit: Note that NodeNext / Node12 support was moved from
TS 4.5
to4.6
.The text was updated successfully, but these errors were encountered: