prettier / prettier-browser-extension Goto Github PK

It probably makes sense to just use npm to install Prettier and bundle the injected content script using something like Webpack.

Issue

Attempting to load the latest version of the extension after a development build (yarn start) gives the following error:

However, loading the extension folder after a production yarn build (ignoring the final compressed zip) works as expected.

I ran a quick git bisect and found that 7cbbc20 was the first commit to introduce this. I'm still trying to narrow down exactly what is causing this - seems like a fairly innocent commit as far as webpack goes. Even reverting the changes to webpack.config.js still causes the issue. @nickmccurdy, any thoughts?

Steps to reproduce

1. Clone the repo
2. yarn
3. yarn start
4. Load the unpacked extension in Chrome

Environment

• macOS Catalina 10.15.3
• Chrome 80.0.3987.163
• Node 12.16.2
• Yarn 1.21.1

I saw the other two issue about the adding the button for stackoverflow and github and which is covered in #3 , which is pretty awesome and loved the current implementation of that.
Is there any other list of thing need to do for this project were contributions can be done . I would be happy to help in those. I guess adding a todo list anywhere in the readme or a separate pinned issue for that will work good.

Really liked the idea of this extension 👌👌👍👍

This may be due to the GitHub redesign, but I'm not able to get it working at all with what's currently in the repo. Will try to look into it and publish a working version ASAP.

The buttons are currently being rendered in such a way that they change the flow of the buttons row. Can we figure out a way for them not to do this?

When I type some text in a supported field on GitHub, clicking the Prettier formatting button prevents me from undoing some or all of the changes to the text field, starting from the most recent. This may confuse users that decide to undo something before formatting, and also makes it difficult to recover from unwanted formatting changes.

web-ext supports a bunch of different stuff like running with Chrome and linting source files, so we should probably take more advantage of it beyond launch:firefox.

Version: d4842e5

Notification settings > Custom routing

Join an organization

Project > Add note

Create a project in any repository/organization/user

Issue (or Pull Request) > Edit

Create an issue

#23 (comment)

It should

• update the version (patch, minor, major) in package.json and manifest.json
• commit the changes
• create a new tag with that version
• push the changes to GitHub

For easier uploads to web store.

When trying to answer this question, I noticed that prettier does not seem to work well when the language lang-tsx is set on Stackoverflow.

It keeps turning

 const ref = useRef<SVGPathElement>(null)

into

const ref = useRef < SVGPathElement > null

When setting the language to either lang-typescript or lang-ts, it formats it correctly.
lang-tsx seems to be a valid specifier according to the guide, and does highlight the syntax correctly.

If you create a HTML/CSS/JS code snippet in Stack Overflow, its content sections should be formatted in the appropriate languages, as if they were normal code blocks.

<!-- begin snippet: js -->

<!-- language: lang-js -->

    ...

<!-- language: lang-css -->

    ...

<!-- language: lang-html -->

    ...

<!-- end snippet -->

Stack Overflow is in the Stack Exchange network of Q&A sites. They all have similar formatting and implementations, so supporting the other sites should be relatively easy.

In order to do this, we'll need a whitelist of all Stack Exchange domains (not all of them use subdomains of https://stackexchange.com/). I recommend separating out the GitHub and Stack Exchange support into separate content scripts so we don't have to duplicate this whitelist into the JS source.

Lists of Stack Exchange sites

• https://stackexchange.com/sites
• https://meta.stackexchange.com/a/81383/232041

#56 (comment)

Right now the button appears only when writing new questions or answers.

These are some ideas based on what I think is useful though I'm not sure we'd want all of them:

• Keyboard shortcut (prettier-js-extension uses Ctrl + Shift + F)
• Button action (clicking on the extension icon in Chrome's extension toolbar)
• Context menu
• Automatic formatting (could work like the VSCode extension and allow auto formatting on any supported file, possible with a debounce/throttle if we hit performance bottlenecks)

Note: These could make #20 easier to implement as we wouldn't have to worry about placing a button in an unknown UI, which could break stuff or look ugly.

Other extensions like prettier-js-extension allow any text box to be used for formatting, which would help make this extension more useful with less code changes. I still think some of the functionality and UI specific to GitHub and Stack Overflow could be useful though.

Moved from #46

In macOS Big Sur (releasing this fall), WebExtensions will be officially supported by Safari, and Apple will provide distribution through the Mac App Store along with a Chrome extension migration tool. If anyone wants Safari support this seems promising, but it looks like we would either have to make users download the extension manually or pay up for the developer account fees ($100 USD/year).

This isn't super straightforward, I'm running into some webpack issues, so just keeping track here

When I am on GitHub in some project directory .if that's a file say index.js then by clicking on some extensions option I should get that file content rerendered with prettier formatted code

Now that the extension is on the Chrome Web Store, we should think about how we want to release this. It looks like automated releases are possible!

As seen below when submitting new comments the Prettier button doesn't always appear straight away on the new comment box.

Stack Overflow allows for language-all comments (see here for more details) in the format of <!-- language-all: lang-html -->. We should add support for this!

and maybe to all StackExchange universe.

I discovered this extension today and was able to figure out how it works, but screenshots would make that much more obvious.

Our prop types aren't using isRequired. This means that all prop types are optional, which could lead to bugs with missing props.

Supporting multiple browsers used to involve writing a different codebase for each set of APIs, but now most major browsers support the WebExtensions standard. I’m guessing the next most requested browser would be Firefox, but we could do a poll to figure out what browsers Prettier users would like to use and research from there.

https://developer.chrome.com/extensions/manifest/icons

I'd like to propose we create a main branch and make that the default branch in this repository.

It's quite more useful there.

The button currently disappears after it is rendered because Stack Overflow renders additional information:

#23 (comment)

Stack Overflow's review queue feature allows users with enough reputation to vote on moderating various changes to questions and answers and has some similar UI to the edit/new question pages. Using this feature requires at least 500 to at most 10,000 reputation depending on the queue. Let me know if you need help testing this, as new users start with 1 reputation.

Their URLs have the form: https://stackoverflow.com/review/QUEUE_TYPE_STRING/QUESTION_ID_INTEGER

Now that this extension has been in existence for a bit, I'd like to discuss how we want it to work going forward. I wrote the initial code for this and therefore set the current direction we're on, but I'm having second thoughts about this approach. The big challenges with the current approach are:

1. The extension has to be aware of the DOM structure of the pages where it can work. This results in broken behavior when a site changes their markup and is a huge maintenance burden. I don't know how quickly we'll be able to respond to sites updating their markup, which could lead to a period of time in which the extension doesn't work. This doesn't seem sustainable from a maintenance perspective and unreliable from a user perspective.
2. Due to the above, adding support for new pages requires someone looking at the markup and figuring out how to make it work (which can be challenging when you're dealing with asynchronously loaded components). This means that users are quite limited in terms of where they can use this extension.

The solution I'd like to propose instead of the current approach:

1. Instead of finding specific textarea elements on specific pages, what if the extension worked on any textarea element on a given page? Rather than adding a button, we could take a few approaches:

2. Allow the user to specify a keybinding that will automatically format the text in a focused textarea element. This is how I personally would want to use it and I think is the simplest approach.

3. Automatically show a floating tooltip with a button on focused textarea elements (or maybe a dropdown that appears on the top right where the extension is visible). We would probably want to add a way for users to limit where these show up, which could be done by adding the ability to enable the extension for certain URLs as well as potentially for given classnames of textareas to look for. If this is configurable, users can use this extension anywhere.

Both of these solutions would allow us to completely forego the need to know the DOM structure of a page, as well as allowing users to use it wherever they want without us having to add support.

Thoughts? If folks are supportive of this idea, I can implement this and see what everyone things. :)

cc @lipis @nickmccurdy

Is there a plan to publish it to Firefox addons? It'll be easy to install for Firefox users.

This means it may submit the form it lives inside, which is probably not desired…

A small note that prettier options can be configured via the extension "Options" menu button would be helpful.

The GitHub buttons currently wait until a user starts typing before rendering. It would be great to figure out some way to know when a new comment is created (maybe an onclick listener, filtering out by what element was clicked and checking the existence of a new comment?). We should be able to traverse the DOM for to find the relevant textarea when the Prettier button is clicked, so it should be able to be a fairly naive check just to scan for any editable textareas that don't have a button.

There's currently a memory leak in the GitHub PR Conversation view when editing an existing comment.

Steps to reproduce

1. Navigate to an existing PR that you have commented on
2. Edit the comment
3. Click the Prettier button repeatedly

I think this is caused by these lines of code, because it is binding the click event listener repeatedly. We can't remove this, though, because it then doesn't bind the button in the Files changed view.

What about committing to the repo the main.js as well so it will be just clone and update :)

Once the basic functionality has been sorted out, we should split the code into smaller modules and add some tests.

I'm not sure why this is happening, as it should be opening in a new tab