Concerns with TypeScript 4.5's Node 12+ ESM Support

For TypeScript 4.5, we've added a new module mode called node12 to better-support running ECMAScript modules in Node.js. Conceptually, the feature is simple - for whatever Node.js does, either match it or overlay something TypeScript-specific that mirrors thes same functionality. This is what TypeScript did for our initial Node.js support (i.e. --moduleResolution node and --module commonjs); however, the feature is much more expansive, and over the past few weeks, a few of us have grown a bit concerned about the complexity.
I recently put together a list of user scenarios and possibly useful scripts for a few people on the team to run through, and we found a few sources of concerns.

Bugs
UX
Ecosystem
User Guidance

Bugs
Most complex software ships with a few bugs. Obviously, we want to avoid them, but the more complex a feature is, the harder it is to cover all the use-cases. As we get closer to our RC date, do we feel confident that what we're shipping has as few blocking bugs as possible?
I would like to say we're close, but the truth is I have no idea. It feels like we'll have to keep trying the features for a bit until we don't run into anything - but we have less than 3 weeks before the RC ships.
Here's a few surprising bugs that need to get fixed before I would feel comfortable shipping node12 in stable.

Code changes breaking module resolution

https://github.com/microsoft/TypeScript/issues/46373
https://github.com/microsoft/TypeScript/issues/46396

Auto-imports not working: https://github.com/microsoft/TypeScript/issues/46332 (technically present in CommonJS)
resolveJsonModule can't be used with node12: https://github.com/microsoft/TypeScript/issues/46362
No errors on extensionless imports from .ts and .tsx files in node12 (unfiled, reported by @andrewbranch)
Strange errors under pnpm (unfiled, reported by @DanielRosenwasser)
package.json changes in packages not tracked (unfiled, reported by @DanielRosenwasser)

UX Concerns
In addition to bugs we found, there are just several UX concerns. Package authoring is already a source of confusion in the TypeScript ecosystem. It's too easy to accidentally shoot yourself in the foot as a package author, and it's too hard to correctly consume misconfigured packages. The node12 mode makes this a whole lot worse. Two filed examples of user confusion:

It's too hard to tell whether you're in an ESM or a CJS file: https://github.com/microsoft/TypeScript/issues/46408
The export field is confusing to configure and diagnose: https://github.com/microsoft/TypeScript/issues/46334
Poor errors on extensionless imports: https://github.com/microsoft/TypeScript/issues/46152

While there might be a lot of "working as intended" behavior here, the question is not about whether it works, but how it works - how do we tell users when something went wrong. I think the current implementation leaves a lot of room for some polish.
But there are some questions about this behavior, and we've had several questions about whether we can simplify it. One motivating question I have is:
When a user creates a new TypeScript project with this mode, when would they not want "type": "module"? Why? Should that be required by default?
We've discussed this a bit, and it seems a bit strange that because we want to cover the "mixed mode" case so much, every Node 12+ user will have to avoid this foot-gun.
I would like to see a world where we say "under this mode, .ts files must be covered by a "type": "module"". .cts can do their own CommonJS thing, but they need to be in a .cts file.
Another motivating question is:
Why would I use node12 today instead of nodenext?
Node 14.8 added top-level await, but Node 12 doesn't have it. I think this omission is enough of a wart that starting at Node 12 is the wrong move.
Ecosystem
The ecosystem is CONFUSING here. Here's a taste of what we've found:

ts-node, Webpack, and Vite don't like imports with .js extensions, but TypeScript expects them. Not all of these can be configured with a plugin.
ts-node, Webpack, and Vite, and Deno are fine with .ts extensions, but TypeScript doesn't allow them!
Many packages that ship types have started supporting export fields, but don't have a types sub-field within export (e.g. RxJS, Vue 3).
Many packages have started supporting export fields, but their @types package might not reflect that.

The last two can be easily fixed over time, though it would be nice to have the team pitch in and help prepare a bit here, especially because it's something that affects our tooling for JavaScript users as well (see https://github.com/microsoft/TypeScript/issues/46339)
However, the first two are real issues with no obvious solutions that fall within our scope.
There's also other considerations like "what about import maps?" Does TypeScript ever see itself leveraging those in some way, and will package managers ever support generating them?
Guidance
With --moduleResolution node, it became clear over time that everyone should use this mode. It made sense for Node.js apps/scripts, and it made sense for front-end apps that were going to go through a bundler. Even apps that didn't actually load from node_modules could take advantage of @types in a fairly straightforward way.
Now we have an ecosystem mismatch between Node.js and bundlers. No bundler is compatible with this new TypeScript mode (and keep in mind, back-end code also occasionally uses a bundler).
Here's some questions I wouldn't know how to answer confidently:

Is our guidance to always use this mode for plain Node.js apps, and let tools "catch up"?
Should new projects that use this mode pick node12 or nodenext?
There's a big foot-gun with forgetting "type": "module" - should we always recommend .mts?

Next Steps
I see us having 3 options on the table:

A mad dash to fix everything - I think this is too hard in the next 2 weeks to pull off.
Keep the feature in, but make it inaccessible until we're ready - I think temporarily removing the feature would be impractical. It would probably take more work to remove it than to fix the issues I've already mentioned. So we might as well keep it in.
Ship with some "experimental" labeling - I think this makes the most sense, but with some caveats to what I mean by "ship". It would make sense to just ship this as "experimental", but I think we should make this feature only work in nightly releases so that people can continue to easily use it, but not depend on a stable version until it's ready.

☝ Actually, I was wrong about this particular example. This may be a common symptom for some packages if their typings are stored in a separate folder from the JS that the export maps point to, like RxJs does. However, if the .d.ts files are colocated with the .js/.mjs/.cjs files pointed to by the export map, this should “just work.” This is the case for async-call-rpc, so the fact that the declaration emitter is complaining here is probably indicative of a module specifier resolution bug. (cc @Jack-Works)

Oh. Yes, I found that package actually exports the correct typing and JS file at /full, not /out/full.

There are some rough edges with the new resolution mode. I've been trying out this mode for two weeks.
The main issues I've hit are:

unstable import resolution issues in IntelliJ IDEA (looks to be related to #46389)
libraries missing a types declaration (@types/koa-route, raw-body)
libraries with an export field but no types condition while the type declarations are in their own directory (rxjs)

Despite all of these issues, I still hope that the new resolution algorithm becomes available on stable TypeScript: the core seems good and bugs/UX can be iterated. The new resolution mode lets me get rid of tons hacks and makes it finally ergonomic to use ESM natively.

I no longer have to manually watch out for explicit extensions in relative imports
I can use exports with subpath mapping to expose my outputDir directly for deep-imports; without having to abuse typeVersions and being fully compatible with npm|yarn link and project references
For complex cases where types are generated directly in the build directory (e.g. using wasm-bindgen), I am now able to use import maps and remove dummy files used just so TypeScript does not complain about missing files.
Other various quality of life improvements such as proper handling of import.meta or __dirname.

I was able to use node12 with Node, webpack, mocha, wasm-bindgen, native node modules and Angular 13.
In my personal experience, all of these improvements strongly outweight the current issues: it makes things so much simpler as it aligns TS behavior's with Node's. I hope that the current issues get fixed soon and I hope that the concern will not delay the new resolution too much.

unstable import resolution issues in IntelliJ IDEA (looks to be related to #46389)

@demurgos did you get the right issue number here? This doesn't sound like it would be related to what you're talking about 🤔

I wanted to link to link the issue 46396: "nodenext alternates between finding and not finding the imported package"
I've double checked my message: I linked it as #46396 but it looks like GitHub failed to resolve it properly. Editing my message to add a single space to force a refresh fixed the rendering.

What if TypeScript 5 assumes "type": "module" by default?
It would be regrettable if we have to add "type": "module" to our package.json in the far future, when many have migrated.

What if TypeScript 5 assumes "type": "module" by default?
It would be regrettable if we have to add "type": "module" to our package.json in the far future, when many have migrated.

Just to be clear it is Node that requires "type": "module" in package.json and that isn't likely to change probably ever. TypeScript just reads the value to understand how Node will run the module, TypeScript doesn't control how the module is run.

at present i think the package.json part is less relevant as that is only a switch for the .js extension inside NodeJs Typescript at present 4.5+ detects the module type via import and ``èxport ``` statments inside the .js files this should not change.
Typescript is not a NodeJS only Product at last i guess that.
ps i still have Javascript Projects without a package.json at all and i use the global installed typescript to typecheck them it works great and it should stay working.

For folks who are interested in testing esm-node out:
npm add<EMAIL_ADDRESS>yarn add<EMAIL_ADDRESS>--dev
pnpm add<EMAIL_ADDRESS>--dev

This is the closest nightly npm release to the RC, so can act as "4.5 but with ESM enabled" for your projects.

Are the node12 and nodenext module options both being dropped for 4.5? Or just node12?

Correct, neither will be available for TS 4.5.

For what it's worth, I can explain ts-node's short term plans around file extensions in import specifiers.
Today we already allow .js extensions in imports when using our node ESM loader hooks.  You can import ./foo.js to execute ./foo.ts.  Our ESM resolver hook understands to resolve .js to .ts when the corresponding TS file is found on disk.
In the near-term, I'm working on adding resolver behaviors to CommonJS so that .js extensions will also work for the CommonJS / require() resolver.  Once these changes are complete, users will be able to specify the .js extension in all imports, whether they are using the ESM loader hooks, the CommonJS hooks, or both.  This should hopefully eliminate a big source of confusion.
I have a pinned issue for this but hesitate to link it here, both to avoid confusing readers and to avoid too many distracting questions.  It's a broad issue describing multiple resolver behaviors, file extensions being just one part of it.

ts-node, Webpack, and Vite don't like imports with .js extensions, but TypeScript expects them. Not all of these can be configured with a plugin.

FYI Vite 2.7.0-beta.3 has added support for imports with .js extensions when the importer is a ts module.

Will it be possible to use native dynamic import(…)https://github.com/microsoft/TypeScript/issues/43329 in TypeScript 4.5 without module: nodenext?

@ExE-Boss the related code is only in the node12 and nodenext features it is not isolated at present but i agree that this could be a extra PR and a extra tsconfig.json setting like transpilDynamicImport. As i see situations where you would want to transpil it and also situations where perserving them is the right choice.

I am mostly excited about support for the "exports" field since it is a key for dual packaging. I hope the "type: module" support to be a secondary concern for now, or at least not something that could slow down "exports".
This was the first Typescript beta I installed because I really wanted "exports". I had some issues, like "exports" not being effective unless a matching "typesVersions" was present. Things could work, but problems were hard to diagnose.

@ExE-Boss it looks like dynamic import isn’t transformed away in module: es2015 and up: playground

FYI Vite 2.7.0-beta.3 has added support for imports with .js extensions when the importer is a ts module.

@sodatea thanks for bringing this to our attention! Do you happen to have a link to an issue/PR on their side where this was discussed? I’d be curious to read about it.

FWIW, as a maintainer of a small corner of the ecosystem, I strongly second this idea:

I would like to see a world where we say "under this mode, .ts files must be covered by a "type": "module"". .cts can do their own CommonJS thing, but they need to be in a .cts file.

While I'm also sympathetic to @weswigham's comments on the design discussion thread, where folks want TS to help bridge the gap, it's not clear to me that you're going to be able to do that in a particularly clean way—and I think it's probably going to be net easier pedagogically and mechanically to tell people something along these lines:

Okay, here's the upgrade flow

Set the new value in tsconfig.json.
Rename all your existing .ts files to .cts.
Make sure all your tests pass!
Convert all .cts files to .ts, with ES module semantics, at will.

That basically matches how I would advise someone to migrate a JS library. It makes ES modules the new default; it preserves all existing behavior; and it also makes the migration status obvious and easy to reason about—and, importantly, finishing the migration is effectively zero-risk: someday you just don't have any CJS files left.
The bigger challenge here is the publication of modules in both modes (supporting exports.require and exports.import, right? I.e. needing separate configs for each mode (presumably extending a base config), with the resulting different semantics, if you choose to publish and support that way. 🤔

@ExE-Boss it looks like dynamic import isn’t transformed away in module: es2015 and up: playground

@andrewbranch  Shouldn't this be documented as a breaking change then?

@sodatea thanks for bringing this to our attention! Do you happen to have a link to an issue/PR on their side where this was discussed? I’d be curious to read about it.

@andrewbranch Yeah, the issue was originally discussed at https://github.com/vitejs/vite/issues/3040 and the fix is https://github.com/vitejs/vite/pull/5510

@ExE-Boss it looks like dynamic import isn’t transformed away in module: es2015 and up: playground

@andrewbranch Shouldn't this be documented as a breaking change then?

No, because that’s the existing behaviour.
What I (and https://github.com/microsoft/TypeScript/issues/43329) want, is to support preserving dynamic import(…) in module: commonjs (and other non‑ES* module types).

@sodatea thanks for the info and thanks for driving that change in Vite! That’s a big step toward reducing friction for TS users who want to use proper ESM anywhere besides Node ❤. It looks like that feature went through without much trouble, but feel free to loop me into TS-related issues in the future if you ever need someone from the team to weigh in or take a look at something!

What I (and #43329) want, is to support preserving dynamic import(…) in module: commonjs

Agreed, since CommonJS supports await import(), then TS with module: commonjs should too 👍
Its not just a nice-to-have, its critical for compatibility as seen here: https://github.com/microsoft/TypeScript/issues/43329#issuecomment-864187283
Perhaps that would need to happen in TS 5.x since it would be a breaking change, or maybe somehow enable with target: esnext.
See Playground for more.

The node12 and nodenext module emit modes include that.

@weswigham Yep you're right!
@orta Perhaps this is a bug in the playground after toggling "module" a few times.
See this video which can be reproduced with this link.

Correct, neither will be available for TS 4.5.

FYI the TS 4.5 release notes make no mention of that, maybe it would be helpful to surface that information? I made an attempt to migrate to ESM at work that failed for unrelated reasons, but I did it under the assumption that Node.js /\ ESM support was going to be available in TS 4.5 stable.
Thank you for your hard work!

Thanks for the heads up - I've opened https://github.com/microsoft/TypeScript-Website/pull/2149.

What version of TypeScript will support Node.js then, since this support got scrubbed from the v4.5 release? I can't find it tracked in any of the upcoming iteration plan issues or issue milestones.

@jaydenseric we're committed to shipping this as soon as it's ready; ideally 4.6, but the possibility of a further slip is always present

I want to talk about an off-topic topic, but actually it's not that off-topic.
Because of the discussion of hard in supporting native ESM in Node.js. I spent a day learning Deno. Amazingly,I found the deno version module is based on ESM,but a little different than what we think esm now today.
And I think maybe the best way is not Node.js world to support ESM native. Maybe it is best to open a new world in deno. And force package writer do something,And may be this can also force Node.js do something.
After all，module thing look like not just the responsibility of TypeScript,is also package writer and runtime thing.

@skimmilk6877 let me give you some insights as Javascript got created there was "No Module System" so People Invented them. The Current JavaScript/ECMAScript standard has well defined Module System and that is the only source of truth for today. Everything else only shims it or transpils to it.

It's worth understanding that the implementations by Deno and Node are both compliant with the spec. So are implementations in browsers which resolve things somewhat differently than either! The spec intentionally allows a string identifier to be resolved in different ways by different implementations. This is a necessary design constraint given the many different environments that JavaScript modules exist in, and it's the only reason it's even possible for Node to add support at all! It's also what has allowed tools as different in implementation details as Ember CLI and webpack and TypeScript to use Node's module system under the hood while allowing developers to author in ES modules for the last 5–6 years even though Node itself didn't yet have built-in support for ES modules.
Happy American Thanksgiving, everyone! 🦃🥧🇺🇸

@chriskrycho sure they are both compilant as both are using v8 which is compilant and both transpil to it and there is no resolve in v8

There are two important ways in which your statements (including your clarification) are misguided at minimum:

Transpilation is not what makes them compliant. Any string is a legitimate identifier in the ES Modules spec, and implementors are free to interpret that string as they like.
The browser is not the only environment that matters, especially for the purposes of designing a module system: other JavaScript contexts and runtimes matter, too! Especially Node!

To take a historical example, Ember’s use of ES Modules[^redesign] was quite different from either the browser/Deno model or the Node module. (There were good reasons for that, given when Ember adopted ES modules!) The Ember modules happened to be compiled to a bunch of AMD modules to run in the browser—not least because the browsers didn’t yet support the ES module spec, but also because the best authoring format isn’t necessarily the same as the most-optimized runtime format.
So, to reiterate, running in a browser or using transpilation is irrelevant. The Node implementation, including all of its resolution rules, is in and of itself spec compliant. So was Ember’s classic modules design. So are browsers’ and Deno’s use of URLs.
I understand (even if I don’t agree with) the idea that all resolution should just happen via URL. It definitely has its attractions. However, that’s simply not what compliance with the spec requires—and that’s actually a very good thing, given how diverse the JS ecosystem is. And, most importantly for this thread: whatever your or my personal tastes or preferences, TypeScript has to support the ecosystems which actually exist.
[^redesign]: currently in the midst of a long transition to use Node module resolution

@chriskrycho good point finaly i found a reason for a new (the next) Programming Language only to drop the existing Ecosystem in favor of a clean one that works. Thanks for your time and inspiration you finally got me on track again the JS/ES thing is dead we need something total new.

GitHubDesktopSetup-x64.msi

It's been about two months now since the last message. Do you know what are the chances we'll get support for Node's ESM in the next stable release?

what is it with developers and wanting plugins in literally everything?

Open-closed principle.

In object-oriented programming, the open–closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification";[1] that is, such an entity can allow its behaviour to be extended without modifying its source code.
https://en.wikipedia.org/wiki/Open–closed_principle

@weswigham you sayed that you want to use exports: { "types": } in package.json but when i add that in current vscode insiders then it yields "types" is not allowed but i am not sure where that comes from. it is not from typescript or is it?

@DanielRosenwasser not sure if this has been reported, I could not find any issues explicitly mentioning it. But it seems the new "module": "nodenext" resolution is ignoring typesVersions, it is not mentioned in the documentation so curious if this was a deliberate decision.
I came across the issue when using the rxjs types, they rely on typesVersions and types to point to the correct files, and also use exports. Playground Link
I am trying to figure out if I should put a PR in to rxjs to add the types key to the exports map or whether this is a bug with TypeScript's new ESM resolution?

@andrewbranch I maintain a package that publishes types and uses package exports. Is there a summary of what we would need to do?

You just need to ensure that typescript@next finds typings for imports of your exports when set to --module nodenext. This will happen automatically if there is a .d.ts file colocated with each .js file referenced by the import map. (IIRC, if these JS files use .mjs or .cts extensions, the declaration files will need to use .d.mts or .d.cts respectively in order to be picked up automatically.) If that’s the case, no changes will be necessary, but you should test and make sure it’s working as expected. If you ship your .d.ts files in a separate folder like RxJS does, you’ll need to add types keys to each leaf entry in exports.

@andrewbranch how is it with exports + types property directly in the package.json not on the exports. they will get completly ignored? i think it would be great to at last fallback to that.

types and typesVersions as top-level fields are always used for require resolution. Any exports at all will block import resolution from using these fields. That’s by design and will not change. I believe types and typesVersions can still be used for import resolution as long as there was no package.json with exports in the way.

We’re aware that RxJS needs an update. If you or someone else makes that PR before we get to it, please ping me on it. Thanks!

I sent a PR for RxJS in October. At the time they were waiting for the feature to be available in stable TS. I assume this is still the case.

It seems a little like too much is trying to be accomplished at once. Importing esm modules seems to work fine right now (even if the imports are extensionless) so I’m not sure why nodenext is being added to moduleResolution (At least as a first step).
What we really need, is compiled output that is esm compatible. So add the extra suffix necessary (.js, .json, /index.js, etc.), and don’t worry about resolution and import syntax changes in the MVP. Leave off the new moduleResultions option for now, and keep defaulting it to node when module is set to nodenext. Also, make the nodenext option dumb, and ignore the package type setting. Add an output extension option so people can choose .js, .css, or .mjs, explicitly. You can make the default for that option smarter, later. No changes needed to existing code (win). None of the side issues that seem to introduced by trying to change the module resolution mechanism (win). Json imports won’t work in node without the experimental flag, but just call it out in the docs and move on.

What we really need, is compiled output that is esm compatible

TSC already supports this: you need to add .js extension to every relative imports.
Unfortunately there is no way to enforce this.

What we really need, is compiled output that is esm compatible

TSC already supports this: you need to add .js extension to every relative imports. Unfortunately there is no way to enforce this.

This does not work when importing a ts file (or will it reinterpret js to mean ts if a ts file exists? Doubting it, but I forget if I’ve tried it yet).

This is a large feature because it's the minimum required to support and check node esm as it actually exists today, as it was introduced alongside a suite of complex resolver features to handle esm/cjs interop. "Just give me [whatever one thing that frustrated me in particular]" sound great, but we find people stop trusting their type checker if it fails to check for common problems, and believe it or not, node's esm is a big source of common problems. Plus, once you put together every request like that, you get the whole feature (every part of this feature came from some request!), but with an even more confusing array of toggleable flags, which definitely isn't going to help us.
If what you describe is all you want and you think you can get away without having proper checking, you're free to use module: esnext with moduleResolution: commonjs alongside a babel transformer that patches your import paths (which we'll never do because the process is error-prone unless you're at the app bundle level, and we don't bundle), which should get what you want; and if that's enough for you, great, but it's far from actually accomplishing our job of checking real code as it exists.

This does not work when importing a ts file (or will it reinterpret js to mean ts if a ts file exists? Doubting it, but I forget if I’ve tried it yet).

This works, I used this in all my projects since more than 1 year. If I am not wrong the release that introduces this also recommand to go this way. This is the only way to have esm-node-compatible code with TSC.
As an example:
// @filename src/a.ts
...

// @filename src/b.ts
import * as a from "./a.js" // this is automatically resolved to src/a.ts by TSC
...

This works, I used this in all my projects since more than 1 year. If I am not wrong the release that introduces this also recommand to go this way. This is the only way to have esm-node-compatible code with TSC.
As an example:
// @filename src/a.ts
...

// @filename src/b.ts
import * as a from "./a.js" // this is automatically resolved to src/a.ts by TSC
...

Ah, I didn’t know that! Thanks!
@weswigham look at that, a path transform.

@Shakeskeyboarde By the way I could like the support of .ts import in order to be compatible with deno...

Plus, we already did the hard work of shipping it (we already did the action items in the OP of this issue, so maybe it's appropriate to close, idk), we're just trying to polish it before it's marked as stablev(it is in the codebase and fairly feature-complete) because it's capable of checking so many more real patterns. ❤
Specifically, for those of you watching at home, we're trying to both make sure its language service features are more bug-free, and we're looking to provide some new type-level syntax that allows reaching across formats and pulling on type information even if your file's default runtime resolution doesn't allow it (which in turn makes declaration emit more reliable). With those in place all we really want is to get more of the people who early-adopted node's exports with TS types to actually list a types condition as well, so we can find types for those exports (if their types aren't adjacent to their js). As embellishment, we're also thinking about how we might be able to help point out common bugs in node export maps, as people can easily misunderstand how they resolve in practice.

@weswigham i do appreciate that. Thank you. I’m just worried because a language I like is making big decisions, and possibly being too clever :).

deno resolution is a separate, even more complex beast, supporting all modern browser features in some scopes (import maps, full url imports), and these new node features in others (it has a node package compat layer), and some custom modifications besides (.ts direct loading, override comments, redirect comments).
I don't think we'd consider it until after we've overhauled a bundler/browser-specific resolver mode first, since it'd need to use such a mode as a base. classic doesn't really map to anything useful nowadays (except maybe not-node_modules-based).

@weswigham i am still for joining the projects rollup and typescript there is a acron to typescript ast and vice versa implementation when the both asts are compatible you can gain a full plugin system for typescript via rollup rollup is basicly a loader not a bundler and it is basicly only a plugin system so a loader with a plugin system.
i am working on that you can contact me by mail and we can schedule something i mentioned that at a few places already. and rollup now got a disk based cache as you can see in the microsoft pwa builder starter example already.

this issue closes: https://github.com/microsoft/TypeScript/issues/33079 is that correct that it is only missing the subpath pattern implementation? while i need to say nightly works with "exports": { ".": { "types": "" } }

This feature should be made available in stable builds, not only nightly and this is why:
We have a project that uses ts-node. ts-node requires a stable peer dependency of typescript.
Thus we cannot update to esm as of yet, since the the node12 module resolution is not available in stable.
Meanwhile a lot of packages that don't use TypeScript switch to esm, which makes it impossible to import those packages ina sync way. Since we are not on esm, there is no toplevel await.
Some of our dependencies like node-fetch, have vulnerabilites in the outdated commonjs verions.
Thus we have to create our own verdaccio instance, relabeling a nightly build to a stable version.
This we break package compatibility of our Open Source MIT licensed packages for other contributors, that don't have access to our private verdaccio instance...
Please label it as unstable, just don't make it fail in stable builds.

It doesn't "fail" - it just issues a warning diagnostic. Everything actually works in stable same as in nightly.

@weswigham sure? For me it skips the emit when using node12 type module resolution with stable semver.

Do you have emitOnError set? Afaik, it's not an unconditionally emit blocking error, though I may be mistaken.

@weswigham Why would I want to emit on error? Isn’t the while thing about typescript to have type safety?

The process will still print the errors, return a nonzero exit code, and the like - you can just still work with a work-in-progress output file. It's so temporary errors while you're working don't block, eg, live reloading for a preview. You still have errors, they just don't block getting a potentially usable output (that also has the same errors).

@weswigham sounds hacky. Either way we would need to adjust CI to ignore errors then. It works in nightly, but nightly is not supported by ts-node. It would just be nice if typescript wouldn’t actively block esm adoption, when it clearly works already in most cases since a lot of upstream security maintenance gets blocked by it. Just label it as unstable, so people know its unstable as is the —experimental-loader api for esm in nodejs. People are using it, sindresorhus has updated a huge part of his modules, so we kind of need to move with it.

@philkunz maybe you should think about delaying the adoption of node12 nodenext resolvers anyway as i am experimenting with it on large mixed mono repo bases i found out that many packages are incompatible with that resolve mode
they do not got a exports: types: fild or other edgecases where they mix main and exports and then typescript does not support at present subPath patterns
go with a file in your project put that into a extra folder create a tsconfig with node resolve for it and then import the dependencies there see consumption of typescript modules.
when you switch for example to node12 only exports: types will get looked up rest gets ignored. there is no fallback.

@vajahath  Its not about the "module", but mainly about module-resolution with nodenext and node12.

@vajahath it’s a good question; I answered there.

@DanielRosenwasser Could you state what the current status is here? I'm using the node12 resolution mode. It works for me and already helped me identifying esm implementation issues in projects like parcel, lit that are being worked on now.
Can we count on node12 being enabled by default in 4.7.0?

Another request, can we drop Node 12, but start from Node 14? Node 14 starts to support top-level await.

I see the comment https://github.com/microsoft/TypeScript/issues/46452#issuecomment-1031697471

One of the things we plan to do before shipping this as stable is auditing the top N most popular npm packages that ship their own types and use package.json exports.

Is adding "types" to "exports" stable enough that package authors can adopt this now in release versions? Or should we be ready but wait? (I have been reading long threads but still unsure!)
Example PR against rxjs: https://github.com/ReactiveX/rxjs/pull/6802/files
And this question prompted by PR for Commander: https://github.com/tj/commander.js/pull/1704

Is adding "types" to "exports" stable enough that package authors can adopt this now in release versions?

100% yes.

Example PR against rxjs

From what I can see, that uses the same types for both the cjs and esm entry points - as far as we know, that means only one of the two exists (cjs if not type:module, esm otherwise). Technically every entry point with a different module kind should probably have its own types entry.

@weswigham what means the term compund condition? can you give me a code example? as far as i am aware typescript can not even handle subPathPatterns and also not nestedConditions at last in the last nightly it could not do that.
so my question what gets combined? do you mean creating some how a conditional wrapper? in a additional file and reference that via that single entry?

what means the term compund condition?

Being very explicit:
"exports": {
  ".": {
    "import": {
      "types": "./types/esm/index.d.mts",
      "default": "./dist/esm/index.mjs"
    },
    "default": {
      "types": "./types/cjs/index.d.ts",
      "default": "./dist/cjs/index.js"
    }
  }
}

It's nesting another conditions object within the one matched.

as far as i am aware typescript can not even handle subPathPatterns

We should, we just don't provide auto-imports for them yet.

there is as far as i am aware not even a condition Selector

Correct, we do not currently allow setting custom conditions like "development" or "production" - just the core "node", "import", "require", "types" (and versioned variants, eg "types@4.8"), and "default" (obviously only one of "require" or "import" is set, depending on usage).

How is syntactic sugar supposed to work? https://nodejs.org/api/packages.html#exports-sugar
{
  "exports": {
    ".": "./main.js"
  }
}

and
{
  "exports": "./main.js"
}

We look for a main.d.ts alongside main.js.

We look for a main.d.ts alongside main.js.

How does compilation work with exports? Do I need to manually generate those d.ts files for each subpath or will tsc handle that?

@jasonwilliams its tsc default behavior to create the files at the same position as the src files if you do not define anything else in your tsconfig you should read the tsconfig docs carefully.

@Jack-Works top level await makes no diffrence in the module resolve mode the 12 is simply indicating 12+ it makes no sense to add every version.

Actually it does. TLA is a module system feature (because it mucks with how modules are loaded and isn't downlevelable), which is why it's enabled in module: nodenext, but not module: node12.

@weswigham but TLA does not change anything not even the order in nodejs there are 2 total indipendent trees for the modules there is even a context function to sync the trees. https://nodejs.org/api/module.html#modulesyncbuiltinesmexports.
sure TLA blocks script execution until the other one is inited but thats it when we would abstract all that we could come out with.
maybe we talk out of different views i for my self speaking from the v8 view of things there are 2 diffrent v8::isolate instances running one for the CJS tree and one for the ESM tree while the CJS tree gets shadowed Copyed one time to the ESM tree thats why https://nodejs.org/api/module.html#modulesyncbuiltinesmexports exists. And as TLA will send only a RPC call to the CJS context if needed to require cache that in the instance and return on the internal Queue that it is done then the linking kicks in.  If it is not CJS where we do TLA on then nothing changes it stays the same interpreted Stack and will finish in one process-nexttick() loop cycle.
So when we say TLA has impact on resolve then only on Resolve in CJS Context. and there it has less impact because of the linking. Things will fail directly if the CJS code does anything after many process-nextticks there  is not much that can be done thats also why https://nodejs.org/api/module.html#modulesyncbuiltinesmexports is documented as there maybe the need to call that from the CJS code after you as the coder Know that you did load fully.
the await call blocks only the instantiation of the current importing script while it is already parsed until the cjs context resolved the module fully instantiated and then link the current state.

The implementation details don't really matter; node 12 esm format files don't support tla. Higher versions of node do in esm files. No version of node supports tla in cjs files. That matrix means it's only enabled for node-ish modes that distinguish between esm and cjs and which are node versions higher than 12, ie, nodenext.

@weswigham thats fully correct but the most people do code for bundlers and all bundlers do support that. I know near no one who directly uses Typescript Compiler Ouput for deployments. So this should be reconsidered some how as it would help to algin the ecosystem out of my view. And the Other Factor that kicks in is NodeJS does not support TLA in CJS context while many other Popular Engines do support that !!!!

If you are targeting bundlers, then you don't need module: node12 and moduleResolution: node12 at all.
Many libraries on NPM are written in TypeScript, transpiled only by TSC, and targeting Node.js. Now they need the support for Node.js ES Module format. Because it's different from bundlers' loose ES Module mode.
We already have module: es2020 that doesn't support TLA and module: es2022 that supports. It's aligned with each real specification version. module: node12 and module: node14 (nodenext now) is definitely the correct direction.

@yume-chan sure that is the right direction to support this exports filds and the even more right direction would be ModuelResolution: importMap including type definitions and then lets create that import map programatical and we are done.

Yeah, node12 and nodenext are for replicating node, not 3rd party tool fakeo runtimes. You can already get some compatible subset of those with existing options.

@frank-dspeed Yeah the core features of moduleResolution: node12 are mandatory file extensions and no auto index.js in folders. For code targeting bundlers I don't think they want these, they only need import maps. So import maps should be its own mode.

@weswigham about fako runtimes are you aware of https://github.com/oracle/graaljs ? https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite&l=6g0-0 search for es4x it outperforms node on so many benchmarks and that is only the tip of the iceberg
It runs ECMAScript directly in the JVM not v8 thats not a fako

@weswigham I'm curious on this statement.

From what I can see, that uses the same types for both the cjs and esm entry points - as far as we know, that means only one of the two exists (cjs if not type:module, esm otherwise). Technically every entry point with a different module kind should probably have its own types entry. (Meaning you should probably use a compound condition)

Because right now we utilize the pattern of shipping a dts, lib, and esm folders, where types are shared between lib and esm. I'm assuming this will no longer be possible.
Are the d.ts files that different between lib and esm (and also mts, etc) that they can't be shared?

I'm assuming this will no longer be possible.

Oh it's possible, it's just also probably wrong, because we'll only get format data for the one entry point, so, eg, the behavior of default-importing your module from an esm module may be wrong. Easiest fix is to make a second file of the correct format that imports and reexports the other entry point. (So an esm-format .d.ts that imports the cjs .d.ts and reexports everything)

(but if you need/use deep imports, you'll need to do that for every possible one - the most accurate analysis we can give is still if your .d.ts files match your .js files 1:1)

@weswigham That's fair. So we'll basically need 2 tsconfig.json files for each build. But this is only really a problem for "web" packages since we provide the dual builds. Node would just be 1.

@milesj why do you get 2 web builds and 1 node build? Chromium supported ESModules far before node.  The only valid case for cjs code is when you use some really deep integrated binary modules with node or you get a case like electron that does that.
they need to depend on the sync behavior of cjs to start the node instances inside of the chromium instance this can not get done async.
also you need cjs in some again syncron cases when you need to patch the environment for example you can got with a none use strict cjs file to patch the nodejs globals.

@frank-dspeed Web builds have esm, which is module like syntax but isn't necessarily .mjs files. It's only for bundlers. This code also doesn't work In node.js so you need lib for unit testing.

@milesj the web doesn't care about file extensions, .mjs means nothing, and Node supports the .js extension with "type": "module" in package.json. Regardless, you should be able to make a single JS module build work in Node and browsers.

@justinfagnani Yeah I'm well aware, I maintain Packemon (https://packemon.dev) so I know all about this. That would be great and all, but unfortunately, the JS ecosystem just isn't fully there yet to entirely switch to ESM. For example, Jest, which is probably the most widely used testing framework, still doesn't handle ESM very well. Once the ecosystem has stabilized, then yeah, we should be able to only ship 1 build.

@milesj but you need the cjs build only for your jest tests others will not use jest with your stuff they will use something that handels esm well for example ava

@frank-dspeed Correct, but still means a package needs 2 builds. I'm using exports to alleviate this problem going forward, hence this discussion.

I see that .cts emits differently in module: commonjs than module: nodenext: in nodenext and node12, dynamic imports are not transformed.  Are there any subtle differences in the emit of .mts between module: esnext and module: nodenext?
My motivation: I'm implementing support for nodenext and node12 in ts-node.  When the typechecker is skipped and/or SWC is enabled, we need to pass the correct options to ts.transpileModule or SWC's API to emit as closely as possible to the way tsc will emit.  I've added logic to emit the two flavors of CommonJS described above, but I'm not sure if there are also two flavors of ESM.

Just like how the cjs flavor in node12 and nodenext is updated from commonjs (by leaving dynamic import as-is to give acces to the esm resolver in cjs), the esm flavor in node12 and nodenext is actually slightly different than esnext - specifically, import = require is allowed, unlike normal esm, and transpiles to an actual require (which we gin up with a createRequire call). A convenient way to skip writing all the createRequire boilerplate yourself when you need access to the cjs resolver.

I see, thank you.  That's actually pretty slick.
If a project has package.json type: module and we need to transform a .ts or .js file, how can we tell ts.transpileModule to emit this esm flavor?  Is our only option to pass a filename that ends in .mts or .mjs?
Also, I am confused by some effects on emit from target and moduleResolution
With target: es2018 or lower import = require is mysteriously elided from emit.  Yet there are no diagnostic errors.  Does this feature require es2018 or higher, and if so, should a diagnostic be raised?
When I specify module:" NodeNext and moduleResolution: Node, an .mts file emits as CommonJS.  Is this because NodeNext expects the resolver to classify files as CJS or ESM, and moduleResolution: Node does not give it the necessary information?

With target: es2018 or lower import = require is mysteriously elided from emit. Yet there are no diagnostic errors. Does this feature require es2018 or higher, and if so, should a diagnostic be raised?

Probably not, I'd make an issue for it. Sounds like something is incorrectly keyed off target instead of module.

When I specify module:" NodeNext and moduleResolution: Node, an .mts file emits as CommonJS. Is this because NodeNext expects the resolver to classify files as CJS or ESM, and moduleResolution: Node does not give it the necessary information?

Yeah - the moduleResolution field is what actually controls specifier and format resolution, in the absence of that being set, the module transform defaults to assuming everything is cjs. It's possible we should just issue a diagnostic on this configuration - having module: nodenext or module: node12 set without one of the moduleResolution modes is probably never what you want (they set the resolution modes hy default, so you have to explicitly override it, but still).

If a project has package.json type: module and we need to transform a .ts or .js file, how can we tell ts.transpileModule to emit this esm flavor? Is our only option to pass a filename that ends in .mts or .mjs?

I think that's probably an OK switch, since you can always rename it back after transpilation and trying to feed in the format through another side channel (just for transpileModule) would be awkward. Minimally (assuming that works now, if not, it's probably an issue worth filing*), that should continue to work even if we decide later it's worth it to add another option to transpileModule just for the node emit modes.

Ok, yeah, passing a fileName string ending in .mts or .mjs to ts.transpileModule appears to be working, so that works for me.

@weswigham why is there this createRequire logic=? out of my view that is the last resort of edge case but by no way a default.
top level import can import CJS by default without createRequire.

From the release announcement:

As a result, it will have to be rewritten to use the extension of the output of foo.ts – so bar.ts will instead have to import from ./foo.js.

I wanted to echo this comment:

On the subject of imports, why couldn't Typescript convert file extensions from *.js to *.ts during compilation? So that a programmer who works in a Typescript project imports files with the *.ts extension.
Importing *.js files in Typescript projects where you work on *.ts files looks... very strange, very aesthetically unpleasant

(I think the author meant from *.ts to *.js)
I have the same question.

We've started this elsewhere (many times), but it's because we can't guarantee a rewrite of all imports, because dynamic import exists, so in our view it's better to continue to normalize writing imports like you're working in the built js (after all, ts extension imports have never been valid in ts). Also makes migrating between ts and js a bit easier - less to change.

We've started this elsewhere (many times) [sic]

I apologize for asking again, but I did search both the PR and this issue, and I couldn't find the answer.

dynamic import exists

Good point. Could it be allowed for static imports only? Dynamic imports would require a JS extension because they're dynamic and cannot always be statically analysed.
You're importing a TS file, not a JS file. Ctrl-clicking the import takes you to a TS file, etc. It just doesn't seem right.

We are not going to discuss module specifier transformation in this issue. See https://github.com/microsoft/TypeScript/issues/16577 and the duplicates that reference it.

We've started this elsewhere (many times), but it's because we can't guarantee a rewrite of all imports, because dynamic import exists, so in our view it's better to continue to normalize writing imports like you're working in the built js (after all, ts extension imports have never been valid in ts). Also makes migrating between ts and js a bit easier - less to change.

@weswigham it would be really great IMO if this were an official recommendation visible to TS embedders like ts-node. When those support .ts imports it makes TypeScript sources less portable.

I think something like https://github.com/microsoft/TypeScript/issues/37582 is more likely than us convincing runtimes and bundlers to artificially disallow imports of .ts. But we can continue that conversation on #37582.

Picking up from https://github.com/microsoft/TypeScript/issues/46452#issuecomment-1073154628, where we talked about how to tell ts.transpileModule to emit this new style of ESM:

If a project has package.json type: module and we need to transform a .ts or .js file, how can we tell ts.transpileModule to emit this esm flavor? Is our only option to pass a filename that ends in .mts or .mjs?

I've found that this trick will not work for .tsx files, since they emit differently from .mts.  There is no file extension I can use to make it emit like a .tsx file in a type=module directory.
.tsx files in package.json type=module directories support:

emitting import foo = require('foo') as import {createRequire as _createRequire} ...  (not possible with tsconfig.json module=esnext)
emitting JSX syntax (not possible when replacing file extension with .mts)

Do you know there are also .mtsx and .ctsx? 🤔

Those extensions are not working for me in TS 4.7.1-rc, are you saying that they are supposed to be supported?
When trying to use an .mtsx file, I get a diagnostic from TS saying "The only supported extensions are '.ts', '.tsx', '.d.ts', '.cts', '.d.cts', '.mts', '.d.mts'."

Oh... I recall those extensions but they don't exist. Strange.
I can found discussion about .mtsx in https://github.com/microsoft/TypeScript/issues/44442 but I don't know the conclusion

It was a long time ago, but I think the conclusion was that we keep the mts / cts parser available to handle JSX code and don't add support for mtsx and ctsx until it's a very obvious pressing need

I tested to confirm: <Foo>foo type assertion syntax is reserved/forbidden in mts/cts.  So although they do not support JSX today, the possibility was kept open.

@andrewbranch @weswigham @DanielRosenwasser this is my answer and final conclusion about Module Systems in Typescript lets fallback to classic resolve what do you think about that https://github.com/frank-dspeed/tc39-proposal-importScripts/blob/main/README.md#typescript it is only a little usecase example but that is the one related to module system chaos.

Arrived here trying to understand how can we incrementally migrate existing TypeScript+React project to ESM. Am I correct in thinking there is at the moment no incremental approach to migrating tsx files (ie we'd have to move them all to ESM in a single go)? And if so - is there a plan to have one? There seems to be surprising lack of information out there regarding this.

Realistically, there is no incremental strategy for migrating to node esm, because you can't import node esm from node cjs (synchronously).

Let me clarify - I can convert my TypeScript *.ts files to *.mts one by one while preserving the rest of the project in cjs. However there doesn't seem to be a way to do similar for *.tsx files.

@weswigham maybe it will be possible in future with help of the new vm.Module api that can at last lead into the sync direction but i found a other little nice thing i can transpil ESM on the fly to require via spawnSync this way the code gets transpiled in sync via a async bundler and the process stays sync i can work with ESM only files as long as i use my loader.

@pbadenski Are you trying to convert .tsx to .mts? Someone correct me if I'm wrong, but cts/mts do not support tsx, as they are Node.js runtimes (cjs/mjs) and JSX is a browser-side feature.

@milesj does that mean .tsx files must only and always be imported from CJS contexts? -- we have whole codebases with lots of .tsx files and would like to incrementally migrate our projects to ESM. #confused 😕

I'll let the TS team clarify, but this is my understanding of how everything currently works.

.cts compiles to .cjs files, which is only usable in Node.js.
.mts compiles to .mjs files, which is also only Node.js.
.ts and .tsx should be used to compile to normal .js, which can be used in the browser or Node.js.

You don't need to use .cts or .mts to support modules/ESM, you use the module setting, ideally in ES2020 or higher (for import.meta). This should also be coupled with the target setting for down-leveling specific features. If you're using Babel/swc to compile your TS files, then those must be configured to output modules.
While those 2 settings compile your files to ESM, you'll still need handle the new Node.js module resolution logic (package exports and imports), which is done through the moduleResolution setting, which should be nodenext. However, do not that the npm ecosystem is not ready for this, as there are many packages with straight broken exports and types.

I am also not on the TS team, but can clarify a couple things:
With NodeNext, .tsx follows the same rules as .ts: it obeys package.json "type"
In past discussions, hypothetical file extensions .mtsx and .ctsx were discussed which would compile to .mjs and .cjs respectively and would follow the same rules as .mts and .cts, with the notable exception that they would allow JSX syntax.  However, those two hypothetical extensions are not supported today.
It is worth remembering that there are use-cases for JSX on nodejs, notably server-side rendering of JSX.
For incrementally migrating tsx from ESM to CJS, assuming you fully understand the issues you will face if you ever try to import ESM from CJS, your most pragmatic option might be to migrate directory-by-directory, creating tiny package.json files with {"type": "module"}

@cspotcode is correct here. I will also add that we reserved JSX-ambiguous syntax in .mts and .cts files so we have the option in the future of allowing those files to contain JSX. So this is indeed a topic where we’re listening to feedback.

@cspotcode I assume you meant "from CJS to ESM" (we're all assuming that ESM is the future right?).

your most pragmatic option might be to migrate directory-by-directory, creating tiny package.json files with {"type": "module"}

How exactly does this work?
Here's the real problem: we've got a non-trivial amount of code. An increasingly large number of critical dependencies are going ESM-only. The ecosystem and TypeScript just don't seem to be ready to help us proceed?
What are we supposed to do? We can't ignore ESM, but we also can't move without the rest of the ecosystem moving?
My dream: TypeScript could have a compatibility mode that figures out how to import the package based on what it discovers during parsing. Our codebase isn't trying to do anything special at the module level. Linter rules or compiler deprecation warnings should flag the few cases we need to update for the module changes. This compatibility mode could take 2x longer to compile, and it still would be worth it, if it makes it easy for people to incrementally migrate to ESM. Allow any imports to include ".ts" extension and have TSC rewrite it during emit.

assuming you fully understand the issues you will face if you ever try to import ESM from CJS

I assume you meant "from CJS to ESM"

I meant that if a CJS file attempts to import an ESM file, it will likely break.
For example, supposing you have two files, foo.tsx which is CommonJS, and bar.tsx which is ESM, and foo attempts to import {functionality} from './hypothetical/components/bar';

I meant that if a CJS file attempts to import an ESM file, it will likely break.

right @cspotcode I hear you. That's the hypothetical "compatibility mode" "migration mode" I'm looking for. Can't something automatically shim an ESM module to make it importable from a CJS module?
I totally understand if this breaks certain performance benefits of ESM or whatever, I'm just baffled as to why this detail can't be hidden from the caller if the calling source-code won't need changes. I can't help that my upstreams are going ESM only, they're transitive dependencies in some or many cases.

@fbartho I don’t quite understand your use case. Why is it that you want to migrate from CJS to ESM file-by-file? Are you writing a self-contained app or a library that others will consume? If the latter, are you trying to provide entrypoints in CJS, ESM, or both?

An increasingly large number of critical dependencies are going ESM-only.

This is definitely a pain, but to be clear, it has nothing to do with TypeScript. There is no way any kind of compatibility mode TypeScript could dream up can get you out of the fundamental async pickle of needing ESM-only dependencies in a CJS context.

Can't something automatically shim an ESM module to make it importable from a CJS module?

No. That’s literally asking to convert an async operation to a synchronous one. This is the interop model that Node chose, which @weswigham (among others) advocated strongly against. But at this point it’s 100% out of our hands. All we can do now is relfect the reality that Node gave us.

Maybe I'm asking the wrong question.
We have a small dozen of nodejs backend applications (cloud functions, express servers, local tools, graphql servers, and frontend react sites), and another small dozen of library packages in a monorepo. We depend on libraries from npmjs some of which are going ESM-only.
 But we do feel responsible for keeping our dependencies up to date, and weekly it seems like we have to mark more and more dependencies as "can't update this one anymore".
What's the right move here? How do we go from "everything is CJS" to whatever future allows our dependencies to stay up to date (via dependabot or similar)?

Gotcha. So, just in case it wasn’t clear, ESM is importable from CJS, but it must be done with dynamic imports, which return a Promise. So, if all of your stuff is already async, you may be able to get away with awaiting for your ESM dependencies to be imported with relatively little fuss. (Well, I don’t want to predict how much fuss that will be, but it can be done.)
Migrating some, but not all, of your files to ESM will not help you with this, because as long as you have any CJS that depends on anything ESM, you’re going to have the infective async problem. Migrating all of your code to ESM will theoretically get you out of trouble, so I suppose you’re wanting to migrate piecemeal just because migrating all in one go is impractical. It is true that TypeScript is currently going to make it difficult for you to migrate TSX files to ESM one at a time because we lack format-specific extensions that support JSX syntax at the moment. Like @cspotcode said, the only way you can control the module format of TSX files is with the "module" key of package.json files. This is something that could change in TypeScript in response to community feedback.
That said, if you are set on eventually migrating everything to ESM, it might not be the worst to do big batches (whole sites/component libraries) of TSX files at one time, since these components surely depend on each other a lot—migrating them file by file might actually be more work than doing them all together.

if you are set on eventually migrating everything to ESM,

You say "if" like I have a choice, but I don't really think I do, dependencies are updating in breaking ways, and I can't exclude them forever, and I don't control the ecosystem packages that rely on them. ¯_(ツ)_/¯
Libs so far:

So let's say hypothetically, I'm willing to do this in batches. (And let's ignore .tsx files for this question). What are the steps?
Everything shares a top-level tsconfig. Each application/library has its own package.json.

What tsconfig changes are needed? I can create a second top-level config for ESM-ready packages to import from as we do the incremental migration if that's helpful.
What package.json changes are needed?
What standard source-level changes are needed?

I know about __dirname -> import.meta.url,
do all local imports need to be migrated to include a .js? (Is that still a requirement?, how do directory-index imports work?)

We depend on libraries from npmjs some of which are going ESM-only.

This is a conscious choice by some package maintainers to try to use their package's popularity to lurch the ecosystem forwards, regardless of how much it harms their users. The node maintainers assumed package authors wouldn't be user hostile and would be willing to ship so called "dual mode" packages that had both esm and cjs sources for a time (or that most users still using cjs would be fine with old package versions), and that those would bridge the gap. In reality, there's little incentive for a library author to do so beyond perceived "legacy user" demand.

For packages that are going to run in Node, setting module to node16 or nodenext should be the only tsconfig change needed. The whole point of this mode is that we model the interplay between CJS and ESM the same way Node does, so there’s certainly no need to try to split your code under two separate tsconfigs.
Assuming that all your code is currently compiling to CJS, you shouldn’t make any package.json changes—this will keep .ts files CJS by default, and you can start converting files to ESM by renaming them .mts. Then someday, you would have the option of reversing this—setting "type": "module" in package.json, which will make .ts files ESM by default, and you can use .cts to have outliers be CJS. Or don’t. You can use all explicit extensions if you like.
For your frontend apps and libraries, you should really consult with whatever bundler you’re using. It may be compiling your dependencies’ ESM code down to something synchronously available by merit of being bundled. These new modes in TypeScript are made specifically for Node. When bundlers do magic stuff, all bets are off.

do all local imports need to be migrated to include a .js? (Is that still a requirement?, how do directory-index imports work?)

In ESM files, yes. There are no directory-index imports in ESM.
Let me stress again—while I’m happy to give you advice, even in this thread here, beyond setting nodenext in your tsconfig.json, none of this has anything to do with TypeScript whatsoever. For working out the logistics of this migration, you would possibly be better served by searching for guides that are specifically about converting Node apps from CJS to ESM.

setting module to node16 or nodenext should be the only tsconfig change needed.

Clarification: this implies correspondingly named values for moduleResolution. If you have explicitly set moduleResolution, you’ll need to either change or delete that too.

I cannot even get Node16 to work
https://user-images.githubusercontent.com/1706381/173172149-a5727838-d928-40d9-993a-84064c0089ce.mov

I cannot even get Node16 to work
ts-socery.mov

Are you using bundled TypeScript from vsc? make sure to use your workspace tsdk with this settings:
{
    "typescript.tsdk": "node_modules/typescript/lib",
}

Place it in .vscode/settings.json or anywhere, really, or you could use globally installed typescript

Are you using bundled TypeScript from vxc (It could be outdated)? Make sure to use your workspace tsdk with this settings:

Even compiling with tsc wasn't working. But re-installing TypeScript did fix it. Thanks :)

What is the recommended way to upgrade large codebases to ESM?

There isn't one. "Upgrading" to esm is s breaking change for a node package, boo way around it.

Yes, but a codemod or similar could exist to add the .js to imports to aid migration. Or a setting to allow imports without extension to work alongside .js so you can gradually migrate imports.
Both of these things are completely feasible and I'm asking if there's already something like that. There's no reason to manually add .js to a million files if you can automate that.

 We don't exactly bundle tools to make moving from target to target easier; it's just not a thing we do.

I understand not bundling codemods, but I was wondering if there was an official or unofficial recommendation on how to migrate to ESM.
Now that some popular packages are moving to ESM only, you can probably expect more and more people going from CJS to ESM. Expanding the docs with a page featuring a guideline or recommendations for migrating to ESM would be very helpful, it will avoid many future Github Issues.
Currently this page covers the technical basics regarding TS and ESM, but a page full on dedicated to migrating would be helpful to many people in the future.
Such page could mention the existence of tools that aid migration, or TS settings that help. From what I've seen the TS team has decided against any setting that allows .js and no extension imports from coexisting. Which is a pity and I hope you reconsider since this would be extremely useful for migrations.
After all the vast majority TS codebases currently use CJS, and in the future if they want to keep up with the npm ecosystem they'll presumably move to ESM. So good docs on this would help numerous projects.

TS team has decided against any setting that allows .js and no extension imports from coexisting

There is a setting, and it’s called “using CommonJS” 🙃. We allow this wherever your module loader does. ESM in Node does not, so we do not.
It may sound like we’re being pedantic here, but our point of view is derived from two principles which may not be obvious to many people reading up on the new nodenext mode:

We don’t believe you should migrate to ESM for the sake of migrating to ESM. (Hence Wesley’s use of scare quotes on your characterization of this as an “upgrade.”)
If you actually have reasons to migrate to ESM, TypeScript should get out of your way. There should basically be no TypeScript-specific steps in your migration beyond using --module nodenext. Once you’ve done that, literally everything you do to make TypeScript happy (including putting .js extensions on your relative imports) is precisely what you would have to do to make Node happy.

This is core to why we don’t have a migration guide. If folks are set on migrating to ESM and seeking guidance, I would encourage them to look for general JS/Node guides on the subject—it shouldn’t have to be specific to TypeScript.
If you hit pain-points that are TypeScript specific (reminder: this does not include adding extensions to module specifiers; this is literally a Node requirement), we’re interested in hearing those—they may be good candidates for docs (if not actual fixes in our code). (FWIW, the area I’m most concerned with here is dealing with dependencies—it’s going to take some time before all the widely used npm packages who use conditional exports get their typings properly configured. For a user migrating to ESM who runs into dependency issues of this nature, there’s not much they can do beyond recognize what the problem is and file an issue with the library, but maybe we can help with that diagnostic step somehow.)

We don’t believe you should migrate to ESM for the sake of migrating to ESM.

I don't think anybody with a large codebase wants to migrate for the sake of migration. TS already gives you import. It's because of dependencies becoming ESM only that people might want to migrate. In fact I assume most people would prefer a flag that was "emit whatever makes Node ESM happy so I can use my ESM dependencies, without changing my current TS imports", because that would be the least amount of work.
But I understand TS is against that and I don't want to start another flamewar with something that has been discussed many times.
So given that some people will need to migrate to ESM, and such people will need to change their imports, I think there should be docs regarding this. And these docs could rephrase what you just explained, that you must change your imports so that they are imports that make Node happy.
But it is a typescript specific step because people are used to TS handling their imports. Sure, once you know how TS with ESM works you can say imports are now not a step specific to TS. But where are you going to get that knowledge?
People looking at general JS guides won't know how TS decided to handle ESM. They can at most make assumptions. And a lot of people, if they assume that now you have to use extensions with tsc too, they might assume that you have to use .ts instead of .js.
I assumed that and many people will assume that too. I'm not arguing against that decision, just stating that there should be good documentation so people don't make these wrong assumptions.
What I propose is having some documentation with something like a checklist for migrating, something like

Make the following changes to your package.json and tsconfig.json.
Change your imports so they have a .js file extension (NOT .ts). Consider using some tools to automate most of this process
Some smaller things to take into account

I see no downside to having such documentation, and while you can argue that you can infer all that from here, having this info concisely presented to those wanting to migrate will help a lot of people, and we'll avoid a lot of erroneous github issues.

In NodeJS ESM is only a good Authoring format not a good Runtime format at all. The Pros of ESM while coding

static analyzeable
easy transpilable / downleveling
when used as is it works in the browser most of the time and even inside nodejs

The parsing and loading speeds of ESM and CJS do total depend on the overall project variables like size module graph time of instantiation.
Cons ESM:

The ESM System to be more exact the specifier lookup is done in the Host that embeds the ES Engine so out of control without engine hooks or modifications. This is defined in the Specs will never change it was a mistake. Workarounds get invented that allow you to create user space ESM Systems.

I don't really get it, you've made a new major version that doesn't support the most trending TypeScript?

Here is a single-file script that automatically adds .js extensions (or /index.js) to the import.
https://gist.github.com/Jack-Works/6ebba47c3fdef50637b10819f3e7e68a

I just want to give a little update:

https://nodejs.org/api/cli.html#-ccondition---conditionscondition

this introduces the next problem:

https://github.com/microsoft/TypeScript/issues/47931

Will the fun ever end?.. But actually I managed to migrate to ESM at last. If anyone needs an example, here's the link https://github.com/lokalise/node-lokalise-api

Hey @andrewbranch what are the remaining concerns keeping this issue open? Most sub tasks seem closed now but not sure if I’m missing something.


Namespaces and Folder Structure

As we are starting to get more and more analyzers it would be a good to restructure to namespaces and folder layout. (Physical and Project Folderx)
Also this would correspond to the namespace
  \CodeCracker                               \* Language Independent                   *\
    \CS                                      \* C# Specific                            *\
      \Design                                \* Design Specific                        *\
        \CatchEmpty                          \* Catch Empty Analyzer                   *\
          CatchEmptyAnalyzer
          CatchEmptyCodeFixProvider
        \CopyEventToVariableBeforeFire       \* CopyEventToVariableBeforeFire Analyzer *\
          Analyzer
          CodeFix
        \EmptyCatchBlock                     \* Empty Catch Analyzer                   *\
          Analyzer
          CodeFix
        \NameOf                              \* NameOf Analyzer                        *\
          Analyzer
          CodeFix
        \StaticConstructorExpection          \* StaticConstructorExpection Analyzer    *\
          Analyzer
          CodeFix
        \UseInvokeMethodToFire               \* UseInvokeMethodToFire Analyzer         *\
          Analyser
          CodeFix
    \VB                                      \* VB Specific                            *\
      \Design                                \* Design Specific                        *\
        \CatchEmpty                          \* Catch Empty Analyzer                   *\
          CatchEmptyAnalyzer
          CatchEmptyCodeFixProvider
        \CopyEventToVariableBeforeFire       \* CopyEventToVariableBeforeFire Analyzer *\
          Analyzer
          CodeFix
        \EmptyCatchBlock                     \* Empty Catch Analyzer                   *\
          Analyzer
          CodeFix
        \NameOf                              \* NameOf Analyzer                        *\
          Analyzer
          CodeFix
        \StaticConstructorExpection          \* StaticConstructorExpection Analyzer    *\
          Analyzer
          CodeFix
        \UseInvokeMethodToFire               \* UseInvokeMethodToFire Analyzer         *\
          Analyser
          CodeFix

I've been working on a number of VB versions of the analyzers. It would be good to consider a \common root level structure as well for utility methods, and common test components.

@AdamSpeight2008 The project is already structured separated by language, both for tests and source. We have discussed it in the past, it is on the closed issues somewhere.
We also discussing having a folder for each Analyzer/Fix pair, but that idea was thought to be unnecessary.
@jwooley Yes, we will have to do that. At this moment it would require some coordination. I prefer we let duplication happen and then we can evolve it. A common utilities project is something we already have in mind. At the moment you can work on the VB project directly, later we will extract the common code.


Different structure in Config file for vaitrace

Hey,
in https://github.com/Xilinx/Vitis-AI/tree/master/tools/Vitis-AI-Profiler#configuration the following structure for the config file for vaitrace is shown:
{
  "options": {
    "runmode": "normal",
    "cmd": "/home/root/Vitis_AI/examples/VART/samples/resnet50/resnet50 /usr/share/vitis_ai_library/models/resnet50/resnet50.xmodel",
    "timeout": 10
  },
  "trace": {
    "enable_trace_list": ["vitis-ai-library", "opencv", "vart", "custom"]
  },
  "trace_custom": []
}

in https://www.xilinx.com/html_docs/vitis_ai/1_3/profiling.html#fwc1591338728789__section_k2s_rq1_vmb the following one is shown:
{
  "options”: {
      "runmode": "normal",
      "cmd": "/usr/share/vitis-ai-library/sample/classification/test_jpeg_classification resnet50 sample.jpg",
      "output": "./trace_resnet50.xat",
      "timeout": 3
  },
  "trace": {
      "enable_trace_list": ["vitis-ai-library", "vart", "custom"],
      "trace_custom": []
  }
}

only the first one with trace_custom outside of trace is working for me.
I tried with Vitis-AI/demo/VART/resnet50 and "trace_custom": ["TopK", "CPUCalcSoftmax"]

thanks @Fabioni , This is an error in the Vitis-AI user document, we have corrected it. The instructions in the github page are correct


Cannot use on Godot 3.5

The error shows when enable plugin
"Unable to load addon script from path: 'res://addons/bordered-polygon-2d/register.gd'. This might be due to a code error in that script. Disabling the addon at 'res://addons/bordered-polygon-2d/plugin.cfg' to prevent further errors."

Hello,
I'm not the owner of this repo, but I stumbled upon this repo and had a similar issue getting the code to work in Godot 4.0.
This issue is likely due to a syntax change between earlier version of Godot 3 and Godot 3.5.
Are you planning to still use Godot 3.5 on your project or switch to Godot 4.0?
If you are planning on switching, I've created a fork of this repo that works in Godot 4.0. Please note the examples have not yet been rewritten in Godot 4.0. It currently supports the basic functionality, but there maybe some slight modifications that may need to be made in order to use this with textures.
If you are sticking with Godot 3.5, you maybe able to edit the existing .gd files in the addon folder in order to get the plugin to work.


Missing data directory

The 2-data directory is missing. Thanks!

Thanks. The 2-data is used for raw data, which is too big, and we put all the raw data online which you can find the link in our manuscript. All the processed data can be found in the 3-data_analysis directory.


Question: Why you use #define to define a function ? What's the different ?

Hi, thanks for your great job!
I am learning SMAA and diving into the source code of it.
In  smaa-weights/shader.frag, there is a line:
#define sampleLevelZeroOffset(t, coord, offset) texture2D(t, coord + float(offset) * texelSize, 0.0)

I don't know the different between #define sampleLevelZeroOffset and vec4 sampleLevelZeroOffset(...).
Could you tell me more about this ?
Thanks !

Hi,
that's a preprocessor macro definition. Macros are no true functions and only serve as placeholders. When the shader code is compiled by the WebGL compiler, all occurances of sampleLevelZeroOffset(t, coord, offset) will be replaced by texture2D(t, coord + float(offset) * texelSize, 0.0).
The main benefit of using macros like these is to reduce code repitition.
There are other uses for custom macros, too. For instance, the original SMAA code heavily relies on macro definitions to handle different shader languages in a single universal shader.
Since you're looking into the SMAA code please note that the SMAA shaders in this library are missing some interesting features such as advanced diagonal pattern detection and corner rounding. Porting these features to WebGL requires a more in-depth understanding of the original algorithms.

Hmm, I am a bit confused.  The macro was defined as:
sampleLevelZeroOffset(t, coord, offset)

But used it as:
sampleLevelZeroOffset(tDiffuse, coords, ivec2(1, 0))

They are not the same. Does the preprocessor can replace t with tDiffuse and replace offset with ivec2(1.0)?

They are not the same. Does the preprocessor can replace t with tDiffuse and replace offset with ivec2(1.0)?

Yes, the compiler does exactly that. It also replaces coords with coords 😄
The GLSL preprocessor directives are pretty much the same as the standard C set of preprocessor directives. If you need more information, you could check out the C macro documentation and the relevant function-like macro section.

@vanruesc Thank you for your help ! 😃


[backport] Support cuSparse generic API

Backport of #3242

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit 83576704a85355e305390df6d23206b406bb96b1, target branch v7) failed with status FAILURE.

#3081 changed the handle type from size_t to intptr_t.

pfnCI, test this please.

Jenkins CI test (for commit de096597ce9731f24cdb4f34f58d79d5c39ff4b4, target branch v7) failed with status FAILURE.

Test failures are unrelated (fix in https://github.com/chainer/chainer-test/pull/594)

pfnCI, test this please.

Jenkins CI test (for commit de096597ce9731f24cdb4f34f58d79d5c39ff4b4, target branch v7) succeeded!

Test passed!


Manually force PDF build and see error messages

Hello,
When a documentation is updated, the HTML build can be forced by a curl command. However, our PDF is not updated. As I can't see any error messages for the PDF build, I do not know what is going on. Is there any way to see what could cause the problem?
Thank you
Kristina
project: mahara

I think breaking out the Build model so that we save specific builds for each type of backend that was built makes a lot of sense. The initial modeling didn't take this into account, so it's just not gotten done.
We'll also need to figure out a decent UI for this. As we already have a bunch of clutter on the project screen. Some kind of third-level tab kind of like the dashboard area might make sense for this.


ModuleNotFoundError: No module named 'tweepy.auth' is happened

Hi, there
I got an issue happened on this code
import tweepy

consumer_key = "XXXXXXXXXXXXXX"
consumer_secret = "YYYYYYYYYYYYYYYYYY"
auth = tweepy.OAuthHandler(consumer_key, consumer_secret)

And these errors have happened.
Traceback (most recent call last): File "test_tweepy.py", line 8, in <module> auth = tweepy.OAuthHandler(consumer_key, consumer_secret) AttributeError: module 'tweepy' has no attribute 'OAuthHandler'
How can I solve this issue?

Your traceback does not correspond with the issue title.
Regardless, do you have a different file or module name tweepy in your path?
For code block usage, see https://help.github.com/articles/creating-and-highlighting-code-blocks/.

Thank you tell me how to use block usage.

do you have a different file or module name tweepy in your path?
No

Tweepy 3.8.0 definitely does not have this issue.
You must have a file or module in your path or current directory that you're importing instead.


feat: add black GHA for changed files

Provide a github action that runs black code formatting in PRs.
I'm trying to configure it such that only changed files are checked.

I agree. Refactoring the requirements management will help a lot here!

Thanks @ahuber21! Looks good to me. @napetrov @Alexsandruss could you please review?

Well it reformats the license because is not pep8 conform

Block comments generally apply to some (or all) code that follows them, and are indented to the same level as that code. Each line of a block comment starts with a # and a single space (unless it is indented text inside the comment).

Therefore black adds the missing whitespace.
The effect of black is well defined and according to the docs, the coding style "can be viewed as a strict subset of PEP 8."
https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html
We already have many style inconsistencies. I would prefer conserving a reasonable commit history for files that do not change often which is why I'm adding black only for changed files. I think the benefits outweigh the downsides (like more inconsistencies). Frequently used/changed files will quickly be aligned to the consistent coding style.

/intelci: run

/intelci: run


Release v1.112.0 - staging → master

Changelog
CloudManager [2024-02-12] - v1.112.0
Fixed:

Error when enabling backups for Linodes in regions with $0 pricing (#10153)
Error notices for $0 regions in LKE Resize and Add Node Pools drawers (#10157)
Error in Enable All Backups drawer when one or more Linode is in a $0 region (#10161)
Display $0.00 prices in Linode Migration dialog (#10166)

Added:

Support for IPv4 Ranges in VPC 'Assign Linodes to subnet' drawer (#10089)
VPC IPv4 address and range to Linode IP Address Table (#10108)
Support for VPC IPv4 Ranges data in Unassign Linodes drawer (#10114)
Support for VPC IPv4 Ranges in Linode Create flow and 'VPC IPv4 Ranges' column to inner Subnets table on VPC Detail page (#10116)

Validation
Changed:

ip_ranges field in LinodeInterfaceSchema no longer limited to 1 element (#10089)

We can disregard the GHA failure above -- that test has been flaky, but I've been unable to reproduce it locally and have tried quite a bit. I think it's a test issue rather than user facing, but either way it has been flaky since before this release so no worries for this PR @cpathipa


How is the event bus streaming data ?

Hi,
i'm trying to monitor the Marathon Event Bus, in order to write a script which deploy my docker containers one by one, but while waiting for the previous one to finish before launching the next one.
I managed to connect to the event bus using PyCurl library, and am having some strange behaviours with how i receive datas from the bus.
Often while monitoring i end up with only a part of the data : {}, and not the totality of it, and i can only get the rest of the data by triggering a new event (which will also have event's data truncated until i trigger a new event).
I did everything on my end to try to figure out if i didn't missed something, like if my handler is only triggered when the buffer has a sufficient amount of data, but didn't manage to get anything out of configuration, so i was wondering if the bus really streams content or if it waits until it has enough information buffered before sending it to the client.
I sincerely hope i've been clear, and thank you in advance for your response, i'll add anything i forgot to include if you need any further information.

Not a Python expert, but you're aware that the Event Bus is using SSE? There are some special client libraries for Python, like https://github.com/mpetazzoni/sseclient
Maybe you can try those clients?

Thanks for responding.
I did try this client, and it's the same deal, it does however help processing data tho, so thanks.
But still, i still have to trigger a new event in order to get the “deployment_success" i should get after deployment_step_success

@Jbrownstone /v2/events uses SSE to stream events. The events are pushed, there is no need to "trigger an event". Please note: deployment_success is send if the deployment is finished, where deployment_step_success is send if one step is finished. If your deployment contains multiple steps, than you will not see deployment_success immediately after deployment_step_success.
An easy way to attach to the stream is curl:
curl :8080/v2/events -H "Accept:text/event-stream"


Wrong spawns file name

from https://dev-cs.ru/threads/30488/#post-153012
[1.00][DEBUG] Editor_LoadSpawns: No spawns file found `addons/amxmodx/data/redm/de_dust2_a.spawns.json`.

cuz https://github.com/wopox1337/ReDeathmatch/blob/e32b54e79c85972e676b105065cda1adbcba8f9e/cstrike/addons/amxmodx/scripting/redm_spawns.sma#L72

Closed due to duplicate #17


port/tests_from_core

Summary by CodeRabbit

New Features

Added new configuration files for the Mycroft system in Brazilian Portuguese and various formats (JSON, YAML).
Introduced unit tests for configuration management to enhance reliability.

Bug Fixes

Removed outdated or unnecessary TTS configuration entries from multiple language files to streamline settings.

Documentation

Added copyright notice and licensing information to the configuration test file.

not sure why tests passed in core but not in this repo, any ideas @NeonDaniel ?

Maybe a difference in configuration patching? Or just the FileWatcher not triggering an update? I've had inconsistent results with changes to config files triggering a reload..


fix(k8s-views-nodes.json): missing instance label

Pull Request
Required Fields
:mag_right: What kind of change is it?

fix

:dart: What has been changed and why do we need it?

Added a missing instance label

Optional Fields
:heavy_check_mark: Which issue(s) this PR fixes?

#68

:tada: This PR is included in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Wrong Exception thrown

Description:
In @map(type='binary')) , when the source stream does not math with the client sending events, it throws up a java.lang.OutOfMemoryError: Java heap space error.

The code is same as the Siddhi query guide with an extra stream variable as name string.
Error looks as follows

This error occurred due to an incompatibility issue in source stream and sent events.
Suggested Labels:
Bug
Affected Product Version:
4.0.0

Can give the sample message you sent as well

Not reproducible with latest binary mapper implementation.


Bug - Thumbnail drag-n-drop

There is a verified bug on Thumbnail drag-n-drop on the current version. Could someone help me fix this please.
Thank you!

I can no longer reproduce on the viewer-demo link provided in that issue. Are you able to?


notification swagger & tests missing

1) EscolaLms\Images\Tests\Api\RateLimitImagesTest::test_rate_limit
Expected response status code [429] but received 302.
Failed asserting that 429 is identical to 302.

/__w/API/API/vendor/laravel/framework/src/Illuminate/Testing/TestResponse.php:177
/__w/API/API/vendor/escolalms/images/tests/Api/RateLimitImagesTest.php:47


CSS background property showing under invalid.deprecated scope despite not being invalid/deprecated.

The background property under transition is showing up under the invalid.deprecated.color.system.css scope, which makes it show up as an error.
However the background property is animatable and not deprecated: MDN docs | W3C docs.

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.67.2
OS Version: Windows 11 Home

Steps to Reproduce:

Create a new css file
Add the following code

.test {
  transition: background;
}

Alternatively :
.test {
  background: white;
}
.test:hover {
  background: red;
  transition: background 2s;
}

Inspect editor tokens and scopes
Hover on background

That scopes comes from the css grammar that is developed at https://github.com/atom/language-css. Can you file the issue there?

That scopes comes from the css grammar that is developed at https://github.com/atom/language-css. Can you file the issue there?

Yes but i'm not sure how to describe the steps to reproduce there, I don't use Atom. Do I just copy-paste the issue still ?

Yes, you can copy paste the same description here, I think that will be clear.

@Monstarrrr thank you for making the issue in atom/language-css! Closing as upstream.


Input, Select always throws error in focusout

Bug Description
Input, Select always throws error in focusout
Expected Behavior
No errors should be thrown
Steps to Reproduce

Go to https://ui5-webcomponents-ngx.netlify.app/?path=/docs/ui5-web-components-main-input--docs&globals=backgrounds.grid:!false
Open the devtool
Focus the demo input
Focus out
You can see the errors thrown

Isolated Example
https://ui5-webcomponents-ngx.netlify.app/?path=/docs/ui5-web-components-main-input--docs&globals=backgrounds.grid:!false
Context

UI5 Web Components version: your demo site version
UI5 Web Components for Angular version: your demo site version
Angular Version: 17
OS/Platform: Windows
Browser: Chrome 121.0.6167.140 (Official Build) (64-bit)
Affected component: Input, Select

Log Output / Stack Trace / Screenshots

Priority

[ ] Low
[x] Medium
[ ] High
[ ] Very High

Hello @xianshenglu the issue will be resolved with the following PR https://github.com/SAP/ui5-webcomponents-ngx/pull/126 and it will be soon merged


usb c170 logitech wecam detection when piugged in and pludded out for conferencing project

Hi sarxos,
I'm using WebcamDetectListnerExample to detect when ever my cam is plugged to usb port
I'm getting the following error,when i do twice plug in and plug out
Auto open method= true
Exception in thread "Thread-5"
com.github.sarxos.webcam.WebcamLockException: Webcam Webcam C170 /dev/video0 has already been locked
at com.github.sarxos.webcam.WebcamLock.lock(WebcamLock.java:224)
at vc.WebcamImage.(WebcamImage.java:39)
at vc.WebcamDiscoveryListenerExample.run(WebcamDiscoveryListenerExample.java:54)
at java.lang.Thread.run(Thread.java:745)

Hi @bablunani,
Thank you for the report.
This duplicates #302. All activities related to this issue will be tracked there.


Issues with large status files

Parsing takes a huge amount of time (and by huge I mean a few seconds) with even a medium size status file.
One thing I'm wanting to use this for is pulling in the nagios status to a custom monitoring interface.
Right now I'm using Merlin to write host/service/status info to a database and reading from there using ActiveRecord, however have had issues moving this (Merlin) to a new system.
Would be nice if I could pass in an argument to for  host statuses, or status for a certain host, or for a service on a host, grep the file, then parse.  I think this might make it a bit better for quick fetching for a web view... just a thought, not sure if it would work.

Yes, it's pretty slow. :( It's even slower on jruby and rubinius. (I guess because of racc issues)
You are probably better off with using regex to parse the status file. I might look into alternative parser generators in the future to see if they are faster. (like parslet)

I did start doing this, actually.
Works pretty quickly except for when I try to actually initialize each status entry as a ruby object it slows it down to almost the same speed, unfortunately.


Application Insights - WebTestLocations_List returns a plain json array as response, instead of wrapped in a json

Originally reported: https://github.com/Azure/azure-sdk-for-go/issues/9284
The swagger defined the response of WebTestLocations_List here, which is expecting the response should be returned as a JSON like this:
{
   "value": [
      // the elements of the list result
   ]
}

instead, the response is just returning an array, like this:
[
   // the elements of the list result
]

This issue is currently blocking go SDK from working properly.

Hi, is there any follow-up on this?


Create UtilityTracker smart contracts

@miquelcabot can you pls put into the ticket the solution you used for this contract?

@miquelcabot @H34D can you update the descriptoon to include a summary of what was implemented and create a list of any outstanding tasks that require new tickets. I am reopening the issue and moving this back to QA until the description has been added to the ticket and any next steps have been ticketed out.
cc @Luka-Loncar @mudler