Re-evaluating Node.js Experimental Features #285
Comments
|
|
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., |
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:
|
I agree with this. 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?
For
Having API with such a message, is that ok to move to |
|
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?) |
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. |
SGTM |
I believe it's time to discuss our policies around experimental features in the project. Features like
--experimental-network-importare 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-policyfeature 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])AsyncHooksbuffer.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-snapshotsNODE_COMPILE_CACHE=dircrypto.hash(algorithm, data[, outputEncoding])socket[Symbol.asyncDispose]()diagnostics_channel.tracingChannel(nameOrChannels)channel.bindStore(store[, transform])channel.unbindStore(store)channel.runStores(context, fn[, thisArg[, ...args]])TracingChanneltracingChannel.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_ALLOWEDERR_REQUIRE_CYCLE_MODULEERR_REQUIRE_ASYNC_MODULEERR_REQUIRE_ESMERR_UNKNOWN_FILE_EXTENSIONERR_UNKNOWN_MODULE_FORMATERR_USE_AFTER_CLOSEERR_NETWORK_IMPORT_BAD_RESPONSEERR_NETWORK_IMPORT_DISALLOWEDimport.meta.dirnameimport.meta.filenameimport.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.parentPathByteLengthQueuingStrategyCompressionStreamCountQueuingStrategyCryptoCryptoKeyCustomEventDecompressionStreamNavigatorReadableByteStreamControllerReadableStreamReadableStreamBYOBReaderReadableStreamBYOBRequestReadableStreamDefaultControllerReadableStreamDefaultReaderSubtleCryptoTextDecoderStreamTextEncoderStream(Feel free to edit this table)
The text was updated successfully, but these errors were encountered: