Repository navigation
Use Cases Meeting #41
Description
Activity
I'd love to participate if my schedule allows for it
edit: I would like to see this happen before our next meeting if the timing can work
Would it make sense to start of with collecting use cases first in the broadest sense possible and then drilling down? E.g. right now "specific existing libraries of specific importance" seems rather abstract. If it's "library X needs Y and has Z users", the decision would become easier (at least for me). Similar with other bullet points: Would there be use cases that are specific to nashorn? Would they sound reasonable to consider? Actually having 1-2 might make that an easier call.
I would suggest a brainstorm google doc and/or issue to understand the problem space before drawing borders.
superceded by doc below
Well my concern is that we have a lot of things in Goals, but they aren't actions that actors (code authors, node program users, etc.) are able to do with a workflow of specific actionable tasks that they are trying to achieve and steps that are required to achieve them. I don't think stating the importance of a specific library would be beneficial, but some use cases are constrained to a very small subset of libraries like how JSDOM is the main library to look towards for a usage of "create an entirely isolated user land module system".So, the use cases document should be about task that can be performed and how in actionable ways / lists of actions. I've setup a google form that we can dump into and try to have before any call takes place at https://goo.gl/forms/4sGpG4OP2oxDG39U2 but am open to changing that form as seems desirable before the call. If something does not fit that form we should try and discuss scope of use cases that are not isolated and are affected by various existing ecosystem concerns.
RE Modules WG meeting:
I'll take up lead for this use case meeting if needed.Reacted by Myles Borins, Jordan Harband, Bradley Farias and Jan Olaf MartinLinking @ceejbot's gist here as well for visibility: https://gist.github.com/ceejbot/d8703c71dd5cfba4ba93e755371e96e7
Do we want to spread the word about this beyond this group / actively seek community input? Or would this just lead to noise and bike shedding?
We might want to flesh it out within ourselves first, before sharing more widely - we'll certainly want a wider audience to ensure we're not missing anything, but the more complete a list we have before that, the easier it will be to minimize noise.
Reacted by Jan Olaf MartinThanks for copying all the existing data! 🎉
I'm fine closing this if some other issue is open w/ the doc link.
Shall we get a PR going to bring in the items from https://gist.github.com/ceejbot/d8703c71dd5cfba4ba93e755371e96e7?
Ah, forgot we were working to the Google doc at https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit.
Once approved and fleshed-out should we aim move those items into this repo though still?
Once approved and fleshed-out should we aim move those items into this repo though still?
Sure, it's good to have these things documented and findable in some way (doc, wiki, link).
- I just updated Google doc with cases handled by our in-house loader but not covered by Node. My guess (and hope!) is that these are applicable to many Node users too. Summary is: 1. Package-rooted specifiers 2. Dependency aliases 3. Defensible package entrypoints 4. Customisation of resolution during tests 5. Restrict dependency access to those in package.json Let me know if you feel these are off-topic, because I fully admit these are all things that are orthogonal to the conversion from CommonJS to ES Modules. My feeling is that now, when we are re-imagining a module system that has been frozen for many years, is a unique time to Get This Right. Equally I do **not** want to impede progress if we regard these as things we are willing to add later. I'd be prepared to elaborate these use-cases on the next call if people think it would be useful.…On 25 March 2018 at 17:29, John-David Dalton ***@***.***> wrote: Sure, it's good to have these things documented and findable in some way *(doc, wiki, link). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#41 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGni9fnn2HGo8LhnVbK65o0-gVI9RwvTks5th8XPgaJpZM4SXgw7> .Reacted by John-David Dalton
I added a few more web-oriented use cases. Is the Google doc the canonical location for now?
Is the Google doc the canonical location for now?
Yep :)
Closing in favor of #55
Since people want to document use cases and also want to avoid speaking to implementation concerns. I would like setup a meeting specifically for that and follow up with that during the summit. During this meeting I want to brainstorm what scope use cases need to be in:
From here we can try and gather use cases and progress with creating a separate document for them. I think some other people were interested in leading this effort, but can help organize this if we get stuck somehow.
I would like also to see if people are interested in use cases being held as a brainstorming discussion during the summit.