Repository navigation
[Feature] Expose getOptionValue via process.getOptionValue #36935
Description
Activity
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.
This is still of interest to us.
Reacted by David Myers and Charles Samborski- moved this from Stale to Pending Triage in Node.js feature requests
on Jan 29, 2023 Reopening because of #46404. However, is providing access to the raw options really the best approach here? This appears to introduce fragility. What if node changes
--conditionsto also allow some other syntax? That would usually be a semver-minor change because it wouldn't break any existing applications, but it would break code that tries to parse the raw options.If it is relevant for applications to determine this particular value and if it is infeasible to parse
execArgv(and/orNODE_OPTIONS), should this particular option be exposed in some other way? cc @nodejs/modulesWhat if node changes
--conditionsto also allow some other syntax? That would usually be a semver-minor change because it wouldn’t break any existing applications, but it would break code that tries to parse the raw options.Yes, but a) we’re very unlikely to change this, as it’s been stable for a few years now (right @guybedford ?) and b) the benefit to users of being able to parse this would feel to me to outweigh our need to possibly change the schema of
--conditionsin a semver-minor. I feel like the same is probably true for most if not all flags (most of which are either boolean or expect a simple string, so are even more unlikely to ever change format).5 remaining items
This is iteration umpteen of the age old discussion of whether node should expose its internal convenience functions. IMO, we've regretted doing that more often than not because it ossifies what was an inconsequential implementation detail before.
Sometimes user JS code simply doesn't have the means to emulate node's internals but it does here; it could be an npm package.
Reacted by Tobias Nießen and Jordan HarbandSometimes user JS code simply doesn't have the means to emulate node's internals but it does here; it could be an npm package.
There are already countless implementation of Node-like resolve algorithms, all with their own little (or big) discrepancies with the algorithms used by Node - sometimes because of shortcuts, sometimes because the maintainer went AWOL, sometimes because implementation is difficult, sometimes because [...].
From my perspective, it's rather the other way around: Node should strive to make more of its internal algorithms available as generic libraries (possibly by publishing them on npm), as otherwise it's very difficult for tooling authors to provide an experience that matches the stock Node one. In my mind, Node should conceptually be just one more consumer of the "@nodejs/resolution-algorithms" package, using dependency injection to provide I/O support.
It’s been on our to-do list for a long time to provide a utility function to expose Node’s internal "exports" resolution. Perhaps this is a more direct solution to your problem?
For reference, these are the functions that we more or less copy-paste from the Node codebase (that doesn't include the
exportsresolution, which is currently handled byresolve.exports):@merceyz is kind of our resident expert on the ESM loader, he might have a couple more utilities in mind.
There are already countless implementation of Node-like resolve algorithms
But that's not what this issue is about. OP already mentions that the alternative to exposing
getOptionValue()is:Manually parse both process.execArgv and process.env.NODE_OPTIONS.
And that could very well be an npm package.
But that's not what this issue is about
Oh, the comment by @GeoffreyBooth changed the discussion towards resolve helpers, so I thought you were commenting about that.
Regarding
getOptionValue(while not OP we're both working on Yarn), it feels to me Node is the one who knows how are parsed the Node flags (it's not part of any public standard), so it should be its responsibility to expose this logic. That said, in the specific--conditionscase, other APIs could work for us. For example exposing the conditions directly:import {conditions} from 'node:module';If it is relevant for applications to determine this particular value and if it is infeasible to parse execArgv (and/or NODE_OPTIONS), should this particular option be exposed in some other way? cc @nodejs/modules
For my usecase (Vite's config loader), exposing the parsed conditions value is sufficient.
I implementedgetOptionValueas I thought it would be useful for others parsing options on their own.Exposing the parsed result instead of
getOptionValueas suggested here (#46404 (comment)) sounds better to me as what I want is the parsed result and not the parse function itself.It’s been on our to-do list for a long time to provide a utility function to expose Node’s internal "exports" resolution. Perhaps this is a more direct solution to your problem?
This would be helpful for many JS-based libraries. But for my usecase, I cannot use that function because Vite relies on esbuild for that part. I need to pass the parsed condition value to esbuild.
This would be helpful for many JS-based libraries. But for my usecase, I cannot use that function because Vite relies on esbuild for that part. I need to pass the parsed condition value to esbuild.
There’s no reason we couldn’t do both, something like
import { conditions } from 'node:module'and exposing various resolution-related methods. If you’d like to volunteer some PRs, they would be welcome. For the resolution ones, you’ll have to figure out how to handle the filesystem calls; like I assume some libraries might want to override thefs.statand other calls that Node’s internal resolution does, so I guess a public API would need to provide options for overriding those. Ditto with whether to take advantage of Node’s internal module cache orpackage.jsoncache, and whether to follow symlinks or not. These could perhaps all be handled via an options bag. Anyway my point is just that it’s not as simple as making an internal method public; there will need to be some thought put into making the public API appropriate for the various use cases that would want such a method. That effort is definitely worthwhile, IMO, but that extra work is a big reason why it hasn’t been done yet.There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
Reacted by Christophe Hurpeau and Ryan SuhartantoThere has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.
Reacted by Ryan Suhartantoคำขอคุณลักษณะของคุณเกี่ยวข้องกับปัญหาหรือไม่ โปรดอธิบาย
**กรณีการใช้งาน:**ฉันกำลังพยายามนำ
"exports"การสนับสนุนไปใช้ภายในตัวแก้ไข PnPซึ่งแก้ไขอัลกอริทึมการแก้ไขโหนด และฉันต้องการให้เป็นไปตามโหนดให้ได้มากที่สุด เพื่อจุดประสงค์นั้น ฉันจำเป็นต้องใช้ ส่วน การแก้ไขเงื่อนไขผู้ใช้ผ่าน--conditionsแฟล็ก ปัญหาคือ Node ไม่ได้ให้วิธีง่ายๆ แก่ฉันในการเข้าถึงค่าที่แก้ไขแล้วของแฟล็ก (เท่าที่ฉันทราบ)ปัญหา:
ค่าตัวเลือกโหนดสามารถมาจาก 2 แห่งที่แตกต่างกัน (เท่าที่ฉันทราบ): อาร์กิวเมนต์ที่ส่งไปยังไบนารีโหนด
NODE_OPTIONSและปัจจุบันโหนดมีฟังก์ชันภายในที่เรียกว่า
getOptionValueส่งคืนค่าของตัวเลือก โดยแก้ไขอาร์กิวเมนต์ทั้งสองที่ส่งไปยังไบนารีของโหนดNODE_OPTIONSและgetOptionValueจะถูกส่งออกเฉพาะในเท่านั้นinternal/optionsจึงไม่สามารถเข้าถึงได้นอกจากนี้ยัง
getOptionValueใช้การใช้งานดั้งเดิมผ่านgetOptionsการoptionsผูกภายใน ซึ่งไม่ได้อยู่ในรายการอนุญาต ดังนั้นโมดูลจึงไม่สามารถเข้าถึงได้ผ่านprocess.bindingการนำไปใช้ใหม่อีกgetOptionValueครั้งอธิบายโซลูชันที่คุณต้องการ
ฉันต้องการวิธีที่จะสามารถใช้งานได้
getOptionValueและวิธีที่ตรงไปตรงมามากที่สุดที่ฉันคิดได้ก็คือการเปิดเผยprocessผ่านprocess.getOptionValueอธิบายทางเลือกที่คุณได้พิจารณา
แยกวิเคราะห์ทั้งสองด้วยตนเอง
process.execArgvและprocess.env.NODE_OPTIONS
Is your feature request related to a problem? Please describe.
Use case: I'm trying to implement
"exports"support inside the PnP resolver which patches the Node resolution algorithm and I want it to be as Node-compliant as possible. For that, I need to implement the resolving user conditions part via the--conditionsflag. The problem is that Node gives me no easy way to access the resolved value of a flag (as far as I'm aware).Problem:
Node option values can come from 2 different places (as far as I'm aware): the arguments passed to the node binary and
NODE_OPTIONS.Node currently has an internal function called
getOptionValuethat returns the value of an option, resolving both the arguments passed to the node binary andNODE_OPTIONS.getOptionValueis only exported ininternal/options, so it can't be accessed.Also,
getOptionValueuses a native implementation viagetOptionsfrom theoptionsinternal binding which isn't whitelisted, so modules can't access it viaprocess.bindingto reimplementgetOptionValue.Describe the solution you'd like
I'd like a way to be able use
getOptionValue, and the most straightforward way I could think of is exposing it onprocessviaprocess.getOptionValue.Describe alternatives you've considered
Manually parse both
process.execArgvandprocess.env.NODE_OPTIONS.