[RFC] Core defintions #4250
Brianzchen
started this conversation in
Ideas
Replies: 2 comments 5 replies
-
I'm no longer involved with the project that created |
Beta Was this translation helpful? Give feedback.
4 replies
-
Seems good to me. I agree that #4 looks like the best option.
Definitely agree with this part. We've had variable success coordinating with the flow team, they have a lot on their plate, so if we can find a solution that is independent that seems idea. I'm a 👍🏼 on this approach. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
RFC style inspired by reactjs
Summary
Create a place to store and pull core definitions for different javascript environments not supported by flow itself.
Basic example
In
/definitions/core/es5.js
In a project after having an
env
value setupWhich adds to the directory
Motivation
Use case from #3755. Requirement to support a unique browser that has different global specs to what is in flow's lib which causes functions to not throw errors on misuse until runtime.
A change of some kind would need to be made for how
core.es5
is currently stored so thatvalidate-def
command works as intended. See #4249Detailed design
As a sibling to
definitions/npm
we havedefinitions/core
which hold module definitions for environments.Unlike npm definitions, these will not have versions associated as they are not tied to any releases or published library, any changes to the environment should continue to improve an already existing definition. But just like npm definitions they will have flow versions support and tests to ensure their existing API's aren't broken.
Users can then install this which will add the definitions into their project.
It starts to highlight a question of whether node vs browser definitions could be managed here instead of flow itself, decoupling definition improvements to the version it was added to in flow. Also flow as of today only had one mode and loads both node and browser definitions which for the most part works seamlessly but can be a headache when dealing with functions that exist in both modes though have very different api's.
But core definitions could become the ideal place to house global definitions, not part of a library that require reuse not based on libraries but users of flow. Such as a
jsx
core definitions could hold all possible props for html elements and more specific elements as global types which can then be used by projects.How to install
This can be handled in a few ways though I learn on
4.
as the solution to implementenv
property which accepts an array of values that we could use to figure out which core libs the user needs installed.browser
+node
.flow-typed install @flow-typed/core
or something similar though less preferred as we generally haveflow-typed install
which should automatically update definitions with any improvements.env
and include settings such asignore
deps and in the future even a proxy registry location.Drawbacks
I don't see any drawbacks necessarily but I do question if this is the right move for the future of how flow is used. The requirement outlined in the Motivation is a special case and the range of cases maybe be limited.
If we were to adopt a solution that interacts with the flow team we can't be as autonomous and that may hinder us if flow team isn't as active as we are. Is this even useful for Meta or should we aim for a solution that allows us to be as autonomous as possible
Alternatives
core.es5
as it isn't compatible with the rest of the system though this breaks the contributor (@RohanHart) who added this in the beginningAdoption strategy
Users install it as needed, no impact to users who don't need special configs
How we teach this
Updating the readme and docs should be enough.
Unresolved questions
Beta Was this translation helpful? Give feedback.
All reactions