You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In .restyler.yaml, we support remote_files to define files to download before starting, so you can centralize any auto-formatter configuration. These files need to be publicly accessible (e.g. as a raw. URL on a public GitHub repository).
Feature
Support remote_files that are private if they're in a GitHub repository accessible to our App installation.
Limitations
You would have to be accessing files in a private GitHub repository, not just anything that requires some form of authentication
You would have to have Restyled installed in a way that allows access to that repository too, either by installing for all, or by including that repository explicitly
Question: how do we surface these limitations clearly if user's experience errors because of them?
Implementation ideas
Restyler has an installation access token it uses for cloning and interacting with the API. Raw files in private repositories are accessible by appending ?token= to their URLs. We could append our token to remote_files[].url when required.
1- Interpolate our access token anywhere we see ${SOMETHING} in the URL
This puts URL construction in the user's hands and so is a more flexible base on which to build this feature. However, since we only support one very specific private source, there'd be no reason to use this flexibility and it would just introduce a place for the user to get something wrong. And, even if we build out support for other private sources, interpolating our GitHub access token into the URL in some other format wouldn't make sense.
2- Support a new private: true|false key
If true, append ?token=... ourselves. This is the best user experience, but is slightly more complex, since we'd should not naively append, but rather parse-append-rebuild, uri-encode, etc, etc. Libraries should make this easy, but it does introduce a new point of failure in handling remote files.
Additional information
Whatever we do here, we should have a consistent behavior for #96.
The text was updated successfully, but these errors were encountered:
Context
In
.restyler.yaml
, we supportremote_files
to define files to download before starting, so you can centralize any auto-formatter configuration. These files need to be publicly accessible (e.g. as araw.
URL on a public GitHub repository).Feature
Support
remote_files
that are private if they're in a GitHub repository accessible to our App installation.Limitations
Question: how do we surface these limitations clearly if user's experience errors because of them?
Implementation ideas
Restyler has an installation access token it uses for cloning and interacting with the API. Raw files in private repositories are accessible by appending
?token=
to their URLs. We could append our token toremote_files[].url
when required.1- Interpolate our access token anywhere we see
${SOMETHING}
in the URLThis puts URL construction in the user's hands and so is a more flexible base on which to build this feature. However, since we only support one very specific private source, there'd be no reason to use this flexibility and it would just introduce a place for the user to get something wrong. And, even if we build out support for other private sources, interpolating our GitHub access token into the URL in some other format wouldn't make sense.
2- Support a new
private: true|false
keyIf
true
, append?token=...
ourselves. This is the best user experience, but is slightly more complex, since we'd should not naively append, but rather parse-append-rebuild, uri-encode, etc, etc. Libraries should make this easy, but it does introduce a new point of failure in handling remote files.Additional information
Whatever we do here, we should have a consistent behavior for #96.
The text was updated successfully, but these errors were encountered: