Initial release

Author: decompil3d

.gitattributes

@@ -0,0 +1,2 @@
+package-lock.json binary
+

.gitignore

@@ -0,0 +1,45 @@
+# Logs
+logs
+*.log
+npm-debug.log*
+
+# Runtime data
+pids
+*.pid
+*.seed
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+.nyc_output
+
+# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (http://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directory
+node_modules
+
+# Optional npm cache directory
+.npm
+
+# Optional REPL history
+.node_repl_history
+
+# User specific stuff
+.idea/
+.DS_Store
+
+.env
+.env.local
+
+# Package items to ignore
+dist
+*.tgz

.npmignore

@@ -0,0 +1,45 @@
+# Logs
+logs
+*.log
+npm-debug.log*
+
+# Runtime data
+pids
+*.pid
+*.seed
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+.nyc_output
+
+# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (http://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directory
+node_modules
+
+# Optional npm cache directory
+.npm
+
+# Optional REPL history
+.node_repl_history
+
+# User specific stuff
+.idea/
+.DS_Store
+
+.env
+.env.local
+
+# Package items to ignore
+test
+*.tgz

.npmrc

@@ -0,0 +1 @@
+registry=https://registry.npmjs.com

CHANGELOG.md

@@ -0,0 +1,5 @@
+# CHANGELOG
+
+### 1.0.0
+
+- Initial Version

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies when
+an individual is representing the project or its community in public spaces.
+Examples of representing a project or community include using an official
+project e-mail address, posting via an official social media account, or acting
+as an appointed representative at an online or offline event. Representation of
+a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at oss@godaddy.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -0,0 +1,124 @@
+# Contributing
+
+Everyone is welcome to contribute to GoDaddy's Open Source Software.
+Contributing doesn’t just mean submitting pull requests. To get involved,
+you can report or triage bugs, and participate in discussions on the
+evolution of each project.
+
+No matter how you want to get involved, we ask that you first learn what’s
+expected of anyone who participates in the project by reading the Contribution
+Guidelines and our [Code of Conduct][coc].
+
+**Please Note:** GitHub is for bug reports and contributions primarily -
+if you have a support question head over to [GoDaddy's Open Source
+Software Slack channel][slack]. You can request an invite
+[here][invite].
+
+## Answering Questions
+
+One of the most important and immediate ways you can support this project is
+to answer questions on [Slack][slack] or [Github][issues]. Whether you’re
+helping a newcomer understand a feature or troubleshooting an edge case with a
+seasoned developer, your knowledge and experience with a programming language
+can go a long way to help others.
+
+## Reporting Bugs
+
+**Do not report potential security vulnerabilities here. Refer to
+[SECURITY.md](./SECURITY.md) for more details about the process of reporting
+security vulnerabilities.**
+
+Before submitting a ticket, please search our [Issue Tracker][issues] to make
+sure it does not already exist and have a simple replication of the behavior. If
+the issue is isolated to one of the dependencies of this project, please create
+a Github issue in that project. All dependencies should be open source software
+and can be found on Github.
+
+Submit a ticket for your issue, assuming one does not already exist:
+  - Create it on the project's [issue Tracker][issues].
+  - Clearly describe the issue by following the template layout
+    - Make sure to include steps to reproduce the bug.
+    - A reproducible (unit) test could be helpful in solving the bug.
+    - Describe the environment that (re)produced the problem.
+
+## Triaging bugs or contributing code
+
+If you're triaging a bug, first make sure that you can reproduce it. Once a bug
+can be reproduced, reduce it to the smallest amount of code possible. Reasoning
+about a sample or unit test that reproduces a bug in just a few lines of code
+is easier than reasoning about a longer sample.
+
+From a practical perspective, contributions are as simple as:
+1. Fork and clone the repo, [see Github's instructions if you need help.][fork]
+1. Create a branch for your PR with `git checkout -b pr/your-branch-name`
+1. Make changes on the branch of your forked repository.
+1. When committing, reference your issue (if present) and include a note about
+  the fix.
+1. Please also add/update unit tests for your changes.
+1. Push the changes to your fork and submit a pull request to the 'main
+   development branch' branch of the projects' repository.
+
+If you are interested in making a large change and feel unsure about its overall
+effect, start with opening an Issue in the project's [Issue Tracker][issues]
+with a high-level proposal and discuss it with the core contributors through
+Github comments or in [Slack][slack]. After reaching a consensus with core
+contributors about the change, discuss the best way to go about implementing it.
+
+> Tip: Keep your master branch pointing at the original repository and make
+>  pull requests from branches on your fork. To do this, run:
+>   ```
+> git remote add upstream https://github.com/godaddy/webpack-rtlcss-plugin.git
+> git fetch upstream
+> git branch --set-upstream-to=upstream/master master
+>   ```
+>   This will add the original repository as a "remote" called "upstream," Then
+>   fetch the git information from that remote, then set your local master
+>   branch to use the upstream master branch whenever you run git pull. Then you
+>   can make all of your pull request branches based on this master branch.
+>   Whenever you want to update your version of master, do a regular git pull.
+
+## Code Review
+
+Any open source project relies heavily on code review to improve software
+quality. All significant changes, by all developers, must be reviewed before
+they are committed to the repository. Code reviews are conducted on GitHub
+through comments on pull requests or commits. The developer responsible for a
+code change is also responsible for making all necessary review-related changes.
+
+Sometimes code reviews will take longer than you would hope for, especially for
+larger features. Here are some accepted ways to speed up review times for your
+patches:
+
+- Review other people’s changes. If you help out, others will more likely be
+willing to do the same for you.
+- Split your change into multiple smaller changes. The smaller your change,
+the higher the probability that somebody will take a quick look at it.
+- Mention the change on [Slack][slack]. If it is urgent, provide reasons why it
+is important to get this change landed. Remember that you are asking for valuable
+time from other professional developers.
+
+**Note that anyone is welcome to review and give feedback on a change, but only
+people with commit access to the repository can approve it.**
+
+## Attribution of Changes
+
+When contributors submit a change to this project, after that change is
+approved, other developers with commit access may commit it for the author. When
+doing so, it is important to retain correct attribution of the contribution.
+Generally speaking, Git handles attribution automatically.
+
+## Code Style and Documentation
+
+Ensure that your contribution follows the standards set by the project's style
+guide with respect to patterns, naming, documentation and testing.
+
+# Additional Resources
+
+- [General GitHub Documentation](https://help.github.com/)
+- [GitHub Pull Request documentation](https://help.github.com/send-pull-requests/)
+
+[issues]: LINK_TO_PROJECTS_ISSUES_ON_GITHUB
+[coc]: ./CODE_OF_CONDUCT.md
+[slack]: https://godaddy-oss.slack.com/
+[fork]: https://help.github.com/en/articles/fork-a-repo
+[invite]: https://godaddy-oss-slack.herokuapp.com

LICENSE

@@ -0,0 +1,21 @@
+The MIT License
+
+Copyright (c) 2020 GoDaddy Operating Company, LLC
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

README.md

@@ -1 +1,30 @@
-# webpack-rtl-plugin
+# webpack-rtlcss-plugin
+
+Webpack plugin that takes a `.css` chunk and processes RTL (right to left) conversion. Unlike other Webpack RTL plugins, this plugin __DOES NOT__ create a separate `.css` file.
+
+Uses [rtlcss] under the hood. For more information on how to utilize [rtlcss] check out the [rtlcss docs](https://rtlcss.com/learn/).
+
+## Install
+
+```sh
+npm install @godaddy/webpack-rtlcss-plugin --save-dev
+```
+
+## Usage
+
+```js
+const RTLPlugin = require('@godaddy/webpack-rtlcss-plugin');
+
+// Within Webpack config
+
+plugins: [
+  ...other webpack plugins
+  new RTLPlugin()
+],
+```
+
+## Example
+
+Check out the [test webpack config](./test/unit/webpack.config.js) to see an example of how `@godaddy/webpack-rtlcss-plugin` works with `mini-css-extract-plugin`.
+
+[rtlcss]: https://github.com/MohammadYounes/rtlcss