[WRONG] `jsc.experimental.keepImportAssertions` is `experimental`, explicitly
Closed this issue · 19 comments
Describe the bug
The bug is described here: TypeStrong/ts-node#2056
With version 1.3.83, swc renames the experimental configuration option jsc.experimental.keepImportAssertions to jsc.experimental.keepImportAttributes as per #7914
Suggestion to keep other libraries working without so much failure:
- Adding jsc.experimental wrong or non-supported keys shouldn't throw an error ( maybe warning )
- Alias renamed keys to the new keys to it still backward compatible
The error during running ts-node:
Failed to deserialize buffer as swc::config::Options
JSON: {"sourceMaps":true,"module":{"noInterop":false,"type":"commonjs","strictMode":true,"ignoreDynamic":false},"swcrc":false,"jsc":{"parser":{"syntax":"typescript","tsx":false,"dynamicImport":true,"importAssertions":true},"target":"es2015","transform":{"legacyDecorator":true,"react":{"throwIfNamespace":false,"useBuiltins":false}},"keepClassNames":false,"experimental":{"keepImportAssertions":true}}}
Caused by:
unknown field `keepImportAssertions`, expected one of `plugins`, `keepImportAttributes`, `emitAssertForImportAttributes`, `cacheRoot`, `disableBuiltinTransformsForInternalTesting` at line 1 column 396
Input code
No response
Config
No response
Playground link
No response
SWC Info output
No response
Expected behavior
The build should be working normally
Actual behavior
No response
Version
1.3.83
Additional context
No response
keepImportAssertions is explixitly marked as an experimental option. Please read docs.
@kdy1 I understand its experimental, what is the harm of throwing a warning instead of error?
It gives a good impression to people who don't understand the word experimental
@kdy1 I understand, although I think warning gives the same impression, error is more obstructive action and not as helpful.
@kdy1 I understand your explanation regarding the option being experimental, yet it appears that ts-node, for some reason, chose to make use of this configuration option. By changing this in swc in a minor patch you are breaking any user of ts-node + swc. Users do not have control over a fix until ts-node merges this PR: https://github.com/TypeStrong/ts-node/pull/2057/files
I've been advertising for this approach on my blog and expect it is quite commonly used. I don't know how long it will take for ts-node to publish a new release, but it would be great if you could revert this change until ts-node has published an update to their project.
My previously-working ts-node installation is now broken after installing the latest @swc/core version.
Reverting to @swc/core@1.3.82 explicitly fixes the issue.
Anyone can help with the quickfix for this?
I don't have keepImportAssertions in any configuration files. Is It somewhere in ts-node internals or so?
@josser The fix is already published as v1.3.84.
I won't add an alias to the deprecated experimental option, though.
Is It somewhere in ts-node internals or so?
ts-node already has the necessary fixes on the main branch, we just need a new release.
Thank you @kdy1, I really think supporting the community to transition smoothly should be more important than debating this issue resolution, but as you could see the fix may or may not land soon in ts-node, and I know everyone will appreciate your support and flexibility on this issue.
And I want to highlight the same approach in nextjs for example when you configure experimental features and they change or get removed - it shows warning and not error.
[0] $ next start
[0] ⚠ Invalid next.config.js options detected:
[0] ⚠ The value at .experimental has an unexpected property, runtime, which is not in the list of allowed properties (appDocumentPreloading, adjustFontFallbacks, adjustFontFallbacksWithSizeAdjust, allowedRevalidateHeaderKeys, amp, clientRouterFilter, clientRouterFilterRedirects, clientRouterFilterAllowedRate, cpus, memoryBasedWorkersCount, craCompat, caseSensitiveRoutes, useDeploymentId, useDeploymentIdServerActions, deploymentId, disableOptimizedLoading, disablePostcssPresetEnv, esmExternals, serverActions, serverActionsBodySizeLimit, extensionAlias, externalDir, externalMiddlewareRewritesResolve, fallbackNodePolyfills, fetchCacheKeyPrefix, forceSwcTransforms, fullySpecified, gzipSize, incrementalCacheHandlerPath, isrFlushToDisk, isrMemoryCacheSize, largePageDataBytes, manualClientBasePath, middlewarePrefetch, nextScriptWorkers, optimizeCss, optimisticClientCache, outputFileTracingRoot, outputFileTracingExcludes, outputFileTracingIgnores, outputFileTracingIncludes, ppr, proxyTimeout, serverComponentsExternalPackages, scrollRestoration, sharedPool, sri, strictNextHead, swcMinify, swcPlugins, swcTraceProfiling, urlImports, workerThreads, webVitalsAttribution, mdxRs, typedRoutes, webpackBuildWorker, turbo, optimizePackageImports, optimizeServerReact, instrumentationHook, turbotrace, logging, serverMinification, serverSourceMaps).
[0] ⚠ See more info here: https://nextjs.org/docs/messages/invalid-next-config
[0] ▲ Next.js 13.5.2
I am aware that you work in vercel's team and sharing the principles of supporting the community to transition to better software, I think this solution is good balanced approach in ensuring library users knows what is the issue and not stopping their workflow or stuck in old version because of it.
Honestly, I'm really against such PR, but I don't want to think/debate about it
Not sure if it's related, but After updating to "@swc/core": "1.3.88"
I get another error with noInterop
JSON: {"sourceMaps":true,"module":{"noInterop":false,"type":"es6","strictMode":true,"ignoreDynamic":false},"swcrc":false,"jsc":{"parser":{"syntax":"typescript","tsx":false,"dynamicImport":true,"importAssertions":true},"target":"es2015","transform":{"legacyDecorator":true,"react":{"throwIfNamespace":false,"useBuiltins":false}},"keepClassNames":false,"experimental":{"keepImportAssertions":true}}}
Caused by:
unknown field `noInterop`, expected `resolveFully` at line 1 column 391
I have opened ts-node issue to remove it TypeStrong/ts-node#2070
Thanks @kdy1
Curios question is there away to replace ts-node with swc fully with type checking?
Thanks @kdy1
Curios question is there away to replace ts-node with swc fully with type checking?
swc doesn't do typechecking, although there is an experimental project to rewrite the TypeScript checker in rust: https://github.com/dudykr/stc (very experimental)
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.