Open RafaelGSS opened 3 weeks ago
Re-evaluate the benefits of the feature. Decide whether to remove the feature entirely or delegate its maintenance to a team.
Absolutely @gireeshpunathil.
About having a call: I don't think a general call is useful in this case. The topics are driven by different groups of people e.g., crypto
, test runner
and AsyncLocalStorage
. I think it would be good to try to get feedback by each group about the individual status of these.
I think it would be good to try to get feedback by each group about the individual status of these.
I think a separate issue with experimental features by topic/team would be good. Maybe a goal would be that for every feature we're leaving as experimental, we both define its stage and create a tracking issue with a to-do list of what's left before it can go stable. We've had tracking issues for several recent experimental features and I've found them useful, and they're good for communicating to users what to expect.
As I've mentioned many times before we have a more general problem with experimental features in terms of that we officially say that experimental features may change or be removed while in practice we don't want to do that due to breaking the ecosystem.
I propose:
- mark async_hooks stable.
I agree with this. However, are we good with that they don't work properly with esm? Or do they?
However, are we good with that they don't work properly with esm? Or do they?
I have a good feeling that they work better now that most of the loader is sync. We should do another test for that.
What if we start top-to-bottom?
AsyncLocalStorage
(cc: @nodejs/diagnostics For AsyncHooks
we have the following mention on the docs:
Stability: 1 - Experimental. Please migrate away from this API, if you can. We do not recommend using the createHook, AsyncHook, and executionAsyncResource APIs as they have usability issues, safety risks, and performance implications. Async context tracking use cases are better served by the stable AsyncLocalStorage API. If you have a use case for createHook, AsyncHook, or executionAsyncResource beyond the context tracking need solved by AsyncLocalStorage or diagnostics data currently provided by Diagnostics Channel, please open an issue at https://github.com/nodejs/node/issues describing your use case so we can create a more purpose-focused API.
Having API with such a message, is that ok to move to stable
? It seems Experimental will always be the place for it until we migrate things away from async_hooks.
Also, I'll go ahead and mark all flags related to the Permission Model as "Re-Evaluated ✅" and keep its status as experimental as we are still developing and getting more feedback along the way.
This thread is going to become unmanageable if we discuss specific APIs here. Can we get a new issue for async hooks?
I would doc-deprecate async_hooks and focus on the migration away from it for AsyncLocalStorage. While it is largely API stable, it's most certainly not stable from the perspective of being a thing you can trust to not crash your app. It's simply not a safe API and its use should not be encouraged.
I had asked previously for use cases not solved by ALS so we could build out some more purpose-focused APIs. There's also probably a use for a resource-tracking API which is reduced to only doing that without conflating it with promises and non-consumable resource types like http parser.
I would strongly suggest not stabilizing async_hooks in the state it is in presently. 😬
--run can stay the same. just quite recently, I bumped it to release candidate. in a couple of releases, I plan to make it stable.
Maybe we should create a new repo for this? And we PR the evaluation as documents that can be easily looked up by posterity?
(or reuse next-10 repo?)
Maybe we should create a new repo for this? And we PR the evaluation as documents that can be easily looked up by posterity?
This is a great idea. The evaluation could also include the todo list for what work remains before a feature can become stable.
@nodejs/next-10 can we transfer it to Next-10 and start creating issues to debate each topic? It should be async, no need to add to the agenda.
@nodejs/next-10 can we transfer it to Next-10 and start creating issues to debate each topic? It should be async, no need to add to the agenda.
SGTM
I believe it's time to discuss our policies around experimental features in the project. Features like
--experimental-network-import
are challenging to assess and maintain, especially when there is no active champion or creator overseeing them.Proposal
I propose that when the creator or champion of an experimental feature becomes inactive, we should:
This approach will help us set clear expectations, assess and review vulnerabilities, and ensure better maintenance of our experimental features.
Recent Example
We recently dropped the
--experimental-policy
feature because:Actionable Steps
To facilitate this discussion, I have written a simple script to list all experimental APIs from
nodejs/node/docs/api/**
. You can find it here.Can we evaluate these experimental features either asynchronously or through a dedicated call?
AsyncLocalStorage.bind(fn)
AsyncLocalStorage.snapshot()
asyncLocalStorage.disable()
asyncLocalStorage.enterWith(store)
asyncLocalStorage.exit(callback[, ...args])
AsyncHooks
buffer.resolveObjectURL(id)
subprocess[Symbol.dispose]()
--allow-addons
--allow-child-process
--allow-fs-read
--allow-fs-write
--allow-wasi
--allow-worker
--build-snapshot
--build-snapshot-config
-C condition
,--conditions=condition
--cpu-prof
--cpu-prof-dir
--cpu-prof-interval
--cpu-prof-name
--disable-warning=code-or-type
--expose-gc
--env-file=config
--experimental-default-type=type
--experimental-detect-module
--experimental-network-imports
--experimental-permission
--experimental-require-module
--experimental-sea-config
--experimental-shadow-realm
--experimental-test-module-mocks
--experimental-test-snapshots
--frozen-intrinsics
--heap-prof
--heap-prof-dir
--heap-prof-interval
--heap-prof-name
--heapsnapshot-near-heap-limit=max_count
--import=module
--jitless
--no-experimental-global-navigator
--run
--snapshot-blob=path
--test-update-snapshots
NODE_COMPILE_CACHE=dir
crypto.hash(algorithm, data[, outputEncoding])
socket[Symbol.asyncDispose]()
diagnostics_channel.tracingChannel(nameOrChannels)
channel.bindStore(store[, transform])
channel.unbindStore(store)
channel.runStores(context, fn[, thisArg[, ...args]])
TracingChannel
tracingChannel.subscribe(subscribers)
tracingChannel.unsubscribe(subscribers)
tracingChannel.traceSync(fn[, context[, thisArg[, ...args]]])
tracingChannel.tracePromise(fn[, context[, thisArg[, ...args]]])
tracingChannel.traceCallback(fn, position, context, thisArg, ...args)
ERR_INPUT_TYPE_NOT_ALLOWED
ERR_REQUIRE_CYCLE_MODULE
ERR_REQUIRE_ASYNC_MODULE
ERR_REQUIRE_ESM
ERR_UNKNOWN_FILE_EXTENSION
ERR_UNKNOWN_MODULE_FORMAT
ERR_USE_AFTER_CLOSE
ERR_NETWORK_IMPORT_BAD_RESPONSE
ERR_NETWORK_IMPORT_DISALLOWED
import.meta.dirname
import.meta.filename
import.meta.resolve(specifier)
events.addAbortListener(signal, listener)
filehandle.readableWebStream([options])
filehandle[Symbol.asyncDispose]()
fsPromises.glob(pattern[, options])
fs.glob(pattern[, options], callback)
fs.openAsBlob(path[, options])
fs.globSync(pattern[, options])
dirent.parentPath
ByteLengthQueuingStrategy
CompressionStream
CountQueuingStrategy
Crypto
CryptoKey
CustomEvent
DecompressionStream
Navigator
ReadableByteStreamController
ReadableStream
ReadableStreamBYOBReader
ReadableStreamBYOBRequest
ReadableStreamDefaultController
ReadableStreamDefaultReader
SubtleCrypto
TextDecoderStream
TextEncoderStream
(Feel free to edit this table)